这是一本半小时即可读完的书，内容不多，不抓细节，阅读体验挺好。

书中亮点

1. “晚点弄”等于“再也不弄”。
2. 程序员遵从不了解混乱代码风险的经理的意愿，这是不专业的做法。
3. 编写整洁代码的程序员就像是艺术家，他能用一系列变化把一块白板变作优雅代码构成的系统。
4. 糟糕代码的理由：一、需求变化背离了初期设计；二、进度太紧张，没法干好活。
5. 糟糕代码的作用：一、维护周期越来越长；二、修复后无法发现的 bug 越来越多；三、最终被时间拖死了产品。
6. 读与写的比例大概为10:1。
7. 让代码比你看的时候更干净。
8. 糟糕代码造成的时间/生产力曲线，如下。

整洁代码

不同人员的定义：

• Bjarne Stroustrup C++之父：

1. 代码逻辑应当直截了当，叫缺陷难以隐藏。
2. 尽量减少依赖关系，使之便于维护。
3. 依据某种分层战略完善错误处理代码。
4. 性能调至最优，省得引诱别人做没规矩的优化。
5. 糟糕的代码引发混乱！别人修改糟糕的代码时，往往会越改越乱。
6. 细节上花心思，如内存泄漏、静态条件代码、前后不一致的命名方式。
7. 整洁的代码力求集中。每个函数、每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染。

• Grady Booch《面向对象分析与设计》作者

1. 整洁的代码简单直接。
2. 整洁的代码如同优美的散文。
3. 整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当地控制语句。

• Dave Thomas，OTI 公司创始人，Eclipse 战略教父

1. 它应当有单元测试和验收测试。
2. 它使用有意义的命名。
3. 它只提供一种而非多种做一件事的途径。
4. 它只有尽量少的依赖关系，而且要明确地定义和提供清晰、尽量少的 API。
5. 代码应通过其字面表达含义，因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。

没有测试的代码不干净。不管它有多优雅，不管有多可读、多易理解，微乎测试，其不洁亦可知也。

• Michael Feathers《修改代码的艺术》作者

整洁的代码总是看起来像是某位特别在意它的人写的。

• Ron Jeffries《极限编程实施》及《C#极限编程探险》作者

1. 能通过所有测试。
2. 没有重复代码。
3. 体现系统中的全部设计理念。
4. 包括尽量少的实体，比如类、方法、函数等。

消除重复和提高表达力让我在整洁代码方面获益良多。

减少重复代码，提高表达力，提早构建简单抽象。

命名

• 花时间命名，因为省下来的时间更多。如果有更好的命名，则尽快替换，这样后续读者会更加的愉悦。
• 如果命名需要注释，那么这个命名就是糟糕的。
• 不要无意义的命名前后缀。如 account === accountInfo，theAccount === account，这样的就是无意义的前后缀。
• 特定用途的数字使用命名特指，起码好找不是么？let tempFour = 4 与 const TEMP_FIVE = 5 这样难道不是更好整理与查找么？
• 专业程序员明确是王道，专业程序员善用其能，编写其他人能理解的代码。
• 类名不应该是动词。
• 方法名应该是动词或动词短语。
• 统一概念词。如HTTP、Fetch、Controller、do、get、post等，不要多词同义。
• 使用解决问题领域名称命名。比如做数学工具，总不能使用杀猪词吧。
• 如果混淆语境，则最好封装成class。比如属性state，都叫这个就分不清了，套个class挺好。
• 不要乱加语境。命名就是 China 的项目，还要给私有类加上 China 前缀么。

函数

• 函数的第一规则是要短小。第二条规则是还要更短小。
• 函数应该做一件事。做好这件事。只做这一件事。
• 尽量单一参数，不要超过三个参数。
• 尽量保证函数有返回值，方便拓展为纯函数。
• 少用标识参数，如true，false这种。可以干脆分裂为两个函数。
• 同样的入参返回同样的结果。避免副作用。