书籍介绍
这本书最锋利的地方，不在于它教了你多少具体技巧，而在于它重新定义了『专业』的门槛。作者把『衡量代码质量的唯一有效标准是 WTF/分钟』——也就是别人读你代码时每分钟发出的吐槽次数——摆到台面上，让『写得出来』和『写得干净』成了两回事。它真正打动人的，是那种近乎偏执的命名洁癖：名要名副其实、要可搜索、要避免编码、要像术语而非俗语。这些看似吹毛求疵的要求，背后是一个朴素判断——代码绝大部分时间是被阅读的，整洁的本质是为未来的读者（包括改代码的自己）减轻认知负荷。它适合那些愿意把写代码当成手艺而非劳作的人；若你只求功能实现，书中不少原则或许显得理想化，但它足以成为反思日常工作的一面镜子。
作者简介
Robert C. “Uncle Bob” Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, C#, Ruby, OO, Design Patterns, UML, Agile Methodologies, and eXtreme programming.
AI导读
核心看点
- 提出WTF/min衡量代码质量，倡导整洁代码准则
- 详解命名、函数、注释、格式等编程最佳实践
- 强调测试代码与生产代码同等重要，需保持整洁
读者共识
- 程序员必读经典，尽早阅读可节省大量维护时间
- 核心在于为后续阅读者减轻认知负荷，提升效率
- 道理虽浅显易懂，但真正落实需长期刻意练习
精彩摘录
- "衡量代码质量的唯一有效标准：WTF/min"
- "1，代码逻辑直接了当，让缺陷难以隐藏 2，尽量减少依赖关系，使之便于维护 3，依据某种分层策略完善错误处理代码 4，性能调至最优，省得引诱别人做没规矩的优化 5，整洁的代码只做一件事 6，简单直接，具有可读性 7，有单元测试和验收测试 8，有意义的命名 9，代码应在字面上表达其含义 10，尽量少的实体：类、方法、函数 11，没有重复代码"
- "1，名副其实：名称不需要注释补充就可见其含义、用途 2，避免误导： （1）系统专有名称不宜作为变量名 （2）提防差别很小的名称，在代码自动完成时容易选错 （3）用字母I和O作为变量名，让人看成1和0 3，做有意义的区分 不要用数字或废话来区分 4，使用读得出来的名称 5，使用可搜索的名称 少用单字母名称或没有名称的数字常量 6，避免使用编码 （1）不必在名称中标明类型，现代语言有完善的类型检查 （2）不必在名称中区别成员变量，应采用自动高亮成员的编译环境 （3）宁可对实现编码，也不要对接口编码 7，避免使用让别人理解成其他领域常用词的名称 8，类名应该是名词或名词短语，不应是动词 9，方法名应"
- "1，短小 （1）不该超过20行 （2）每个代码块（if， else，while）应该只有一行，包含一个函数 2，只做一件事 如果能拆成几个函数，就不是只做一件事 3，每个函数一个抽象层次 自顶向下的抽象层次 4，switch语句 用于创建多态对象，并隐藏在抽象工厂中 5，使用描述性的名称 6，尽量避免多余2个参数 （1）使用返回值而不是输出参数 （2）不要用标识参数，即向函数传入bool值，应该写成两个函数 （3）如果一定需要多个参数，那么可能需要对参数进行封装 7，无副作用 尽量少做不是函数名称表明的事情 8，使用异常代替返回错误码 （1）把try，catch从正常流程中分离开 9，消除重复"
- "1，尽量减少注释量，用代码本身说明问题 （1）代码常常变动，注释却不能跟着变 （2）只有代码是唯一准确的信息来源 （3）创建一个和注释所言相同的函数来代替注释 2，好的注释 （1）法律信息 （2）解释程序员的意图 （3）警示其他程序员某种后果 （4）TODO 定期删除不需要的 （5）公共API中的javadoc 3，坏的注释 （1）喃喃自语，只有作者自己能看懂 （2）多余的注释 不一定比代码精到 （3）不是每个函数和变量都要有javadoc （4）日志式注释，修改记录 （5）能用函数或变量时就别用注释 （6）用代码控制系统，而不是注释表明归属 （7）不要保留注释掉的代码，利用源代码控制系统"
- "1，垂直距离 （1）变量声明尽可能靠近使用位置，本地变量应在函数顶部出现 （2）实体变量应在类的顶部声明 （3）相关函数放在一起 （4）函数的排列顺序保持其相互调用的顺序 2，水平位置 （1）一行代码尽量短，不超过100-120字符 （2）用空格将相关性弱的分开：加减法，赋值，乘法因子见无需空格 （3）声明和赋值不需要水平对齐 （4）缩进 空循环容易忽略行末的分号，要括号包围空循环。"
- "1，TDD三定律 （1）在编写不能通过的单元测试前，不能编写生产代码 （2）只可编写刚好无法通过的单元测试，不能编译也不算通过 （3）只可编写刚好足以通过当前失败测试的生产代码 2，测试代码和生产代码一样重要，一样需要整洁 3，每个测试一个断言，每个测试一个概念"
- "1，并发防御原则 （1）单一权责：方法/类/组件应当只有一个修改的理由 （2）限制数据作用域 （3）使用数据副本避免共享数据 （4）线程应尽可能独立 2，了解常见的执行模型：生产者-消费者，读者-作者，宴席哲学家 3，警惕同步方法之间的依赖 4，保持同步区微小 5，尽早考虑关闭的代码，注意线程之间的依赖关系 6，测试线程代码 （1）将伪失败看作可能的线程问题 （2）先使非线程代码工作 （3）运行多于处理器数量的线程 （4）在不同平台上运行 （5）手动插入调试的试错代码"
用户评论
verbose
一个有故事的老男人
和同组同事在周会上读了一年多的书。觉得书中原则可简化成「为之后阅读/修改代码的自己或他人减轻认知负荷」。
醍醐灌顶，每一个程序猿都应该尽早读的一本书，早一天读也就少一天浪费他人和自己的生命了~
Aweshhome!
这如同与前辈关于代码可阅读性的一场谈话。不敢保证我同意书里的每一句话，但本书提供了一个senior&experienced的视角看待代码，这让我受益良多
老外程序员真的敬业，不放过任何细节。读了一遍，感觉还是需要大量实践才能真正理解里面的精髓
自从读完clean code,看见旧代码就想重构(不是
刚开始写代码的时候读很有用
后面几章java味太冲了直接过了. 前面几章讲的太好了, 给了非常有用的原则. 比如函数应该只做一件事, 参数不要太多, 尽量不用swtich(如果一定要用, 最好只出现一次, 比如factory pattern create object的时候); talk to friends, not to strangers (不要x.foo().bar()这样); 用exception代替error code, 不要返回null, 也不要传null, 考虑使用一个特殊值代替(比如python可以考虑返回空数组[], cxx17可以用std::optional); 用第三方代码, 不要直接call raw api, 最好写一个adapter, 这样对方更新了代码对自己影响小;一定要写unittest
Prentice Hall的其他书籍查看全部
Signal and Power Integrity - Simplified
Core Java, Volume I (10th Edition)
Fundamentals of Applied Electromagnetics
Reseau
Core Python Applications Programming
Financial Accounting Theory
下载
收藏