书籍介绍
这本书最打动人的，是它逼着你重新审视那些习以为常的编程习惯。它提出一个近乎武断的标准：衡量代码质量的唯一有效指标是 WTF/min——别人读你代码时每分钟发出的吐槽。这个角度让'整洁'不再是抽象美德，而成了可被量化的协作成本。书中反复强调：不要盲从惯例，要联系实际分析得失。它告诉你注释是不得已而为之，好代码本就不该需要注释；函数应只做一件事、参数不超过两三个。但也有人读到十几章就放弃，因为大量代码范例占了太多篇幅。它适合愿意为长期维护付出代价的程序员，也提醒技术经理：代码质量与架构、管理同样攸关。真正读下去的人会说，这是为自己而写，因为整洁最终惠及的是接手代码的自己。
AI导读
核心看点
- 代码整洁度与质量成正比，奠定维护基础
- 涵盖命名、函数、注释等具体编程实践
- 童子军规则：离开时让代码比来时更干净
读者共识
- 写代码如写文章，追求自解释与简洁
- 丑陋代码是坑，迟早要填，尽早清理
- 经典必读，虽观点浅显但易被忽视
精彩摘录
- "衡量代码质量的唯一有效标准：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）手动插入调试的试错代码"
目录
Chapter I: Clean Code
There Will Be Code
Bad Code
The Total Cost of Owning a Mess
The Grand Redesign in the Sky
显示全部
用户评论
丑陋的程序其实就是挖坑，自己早晚要填的
专讲代码风格，新鲜观点不少，比如：注释是不得已为之的，好的代码一目了然不需要注释；函数最好没有参数，或者只有一两个参数……最重要的，不要盲从惯例（比如程序必须有注释），要联系实际、分析得失。
不错，学到很多。断断续续看的，今天一口气读完最后三章，很是高效。
建议阅读的时候先读17章（带有总结性），然后带着感兴趣的内容再往前看
很赞！实用，一些以前踩过的坑作者都提到了。
对于怎样写一份风格良好的代码，概念更很清晰了。
有些规范写多了已经潜移默化了，看了这本才知道为什么这样写才是clean的
从编程一年的菜鸟到数十年的老手精英，都值得一读
读完中文版，再来读英文版，知识点早已看完，只为重温经典，学习英文。
非常值得程序员读一读，甚至想把他作为公司读物给大家展开。
希望每个学校都开一门必修课上这个 @2019-03-06 04:41:28
每个软件工程师都应该读的经典著作，代码不仅是给计算机执行的，也是给人阅读的。
下载
收藏