勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）。
代码混乱的代价：
随着混乱的增加，团队生产力也持续下降，趋向于零。当生产力下降时，管理层就只有一件事可做了：增加
更多人手到项目中，期望提升生产力。可是新人并不熟悉系统的设计。他们搞不清楚什么样的修改符合设计意图，
什么样的修改违背设计意图。而且，他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们制造
更多的混乱，驱动生产力向零那端不断下降。
image.png
- 《C++程序设计语言》）一书作者，Bjarne
我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，
使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的
优化，搞出一堆混乱来。整洁的代码只做好一件事。
Bjarne 也提到完善错误处理代码。往深处说就是在细节上花心思。敷衍了事的错误处理代码，只是程序员忽视细节的一种表现。此外还有内存泄漏，还有竞态条件代码。还有前后不一致的命名方式。结果就是凸现出整洁代码对细节的重视。
糟糕的代码引发混乱！别人修改糟糕的代码时，往往会越改越烂。
减少重复代码，提高表达力，提早构建简单抽象
命名规则：
名副其实、见名知意
避免误导
做有意义的区分
使用读的出来的名称
使用可搜索的名称
避免使用编码
避免思维映射
类名
方法名
别扮可爱
每个概念对应一个词
别用双关语
使用解决方案领域名称
使用源自所涉问题领域的名称
添加有意义的语境
不要添加没用的语境
函数：
函数的第一规则是要短小，第二规则是还要更短小
只做一件事
每个函数一个抽象层级
switch语句
使用描述性名称
函数参数
无副作用
分割指令与询问
使用异常替代返回错误码
别重复自己
结构化编程
