代码整洁之道-读书笔记

• 勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）。

• 代码混乱的代价：

随着混乱的增加，团队生产力也持续下降，趋向于零。当生产力下降时，管理层就只有一件事可做了：增加

更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图，

什么样的修改违背设计意图。而且，他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们制造

更多的混乱，驱动生产力向零那端不断下降。

image.png

• 《C++程序设计语言》）一书作者，Bjarne

我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，

使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的

优化，搞出一堆混乱来。整洁的代码只做好一件事。

• Bjarne 也提到完善错误处理代码。往深处说就是在细节上花心思。敷衍了事的错误处理代码，只是程序员忽视细节的一种表现。此外还有内存泄漏，还有竞态条件代码。还有前后不一致的命名方式。结果就是凸现出整洁代码对细节的重视。

• 糟糕的代码引发混乱！别人修改糟糕的代码时，往往会越改越烂。

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

命名规则：

1. 名副其实、见名知意

2. 避免误导

3. 做有意义的区分

4. 使用读的出来的名称

5. 使用可搜索的名称

6. 避免使用编码

7. 避免思维映射

8. 类名

9. 方法名

10. 别扮可爱

11. 每个概念对应一个词

12. 别用双关语

13. 使用解决方案领域名称

14. 使用源自所涉问题领域的名称

15. 添加有意义的语境

16. 不要添加没用的语境

函数：

1. 函数的第一规则是要短小，第二规则是还要更短小

2. 只做一件事

3. 每个函数一个抽象层级

4. switch语句

5. 使用描述性名称

6. 函数参数

7. 无副作用

8. 分割指令与询问

9. 使用异常替代返回错误码

10. 别重复自己

11. 结构化编程