1、勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）---->及时清理烂代码
2、花时间保持代码整洁不但有关效率，还有关生存。
3、赶上期限的唯一方法—做得快的唯一方法 —就是始终尽可能保持代码整洁。
4、代码逻辑应当直截了当，叫缺陷难以隐藏；
尽量减少依赖关系，使之便于维护；
依据某种分层战略完善错误处理代码；
性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来
整洁的代码只做好一件事。
5、糟糕的代码引发混乱！别人修改糟糕的代码时，往往会越改越烂。
6、敷衍了事的错误处理代码，只是程序员忽视细节的一种表现。
此外还有内存泄漏，
还有竞态条件代码，
还有前后不一致的命名方式。
7、整洁的代码力求集中。
每个函数、每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染。
8、整洁的代码简单直接。
整洁的代码如同优美的散文。
整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
9、代码应当讲述事实，不引人猜测。它只该包含必需之物。
10、整洁的代码应可由作者之外的开发者阅读和增补。它应当有单元测试和验收测试。它使用有意义
的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系，而且要明确地定义
和提供清晰、尽量少的 API。代码应通过其字面表达含义，因为不同的语言导致并非所有必需信
息均可通过代码自身清晰表达。
11、没有测试的代码不干净。不管它有多优雅，不管有多可读、多易理解，微乎测试，其不洁亦可知也。
12、整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地
13、简单代码规则
— 能通过所有测试；
— 没有重复代码；
— 体现系统中的全部设计理念；
— 包括尽量少的实体，比如类、方法、函数等
14、减少重复代码，提高表达力，提早构建简单抽象。
15、取好名字的几条简单规则
--名副其实
--避免误导
--做有意义的区分
--使用读得出来的名称
--使用可搜索的名称
--避免使用编码
--避免思维映射
--别用双关语
--别扮可爱
--使用源自所涉问题领域的名称
--添加有意义的语境
--不要添加没用的语境
16、Variable 一词永远不应当出现在变量名中。Table 一词永远不应当出现在表名中
17、类名和对象名应该是名词或名词短语，如 Customer、WikiPage、Account 和 AddressParser。
避免使用 Manager、Processor、Data 或 Info 这样的类名。类名不应当是动词。
方法名应当是动词或动词短语，如 postPayment、deletePage 或 save。
属性访问器、修改器和断言应该根据其值命名，并依 Javabean 标准加上 get、set 和 is 前缀。
18、函数的第一规则是要短小。第二条规则是还要更短小（函数应该做一件事。做好这件事。只做这一件事）
19、最理想的参数数量是零（零参数函数），其次是一（单参数函数），再次是二（双参数函数），应尽量避免三（三参数函数）。
有足够特殊的理由才能用三个以上参数（多参数函数）—所以无论如何也不要这么做。
20、标识参数丑陋不堪。向函数传入布尔值简直就是骇人听闻的做法。这样做，方法签名立刻变得复杂起来，大声宣布本函数不止做一件事。
如果标识为 true 将会这样做，标识为 false 则会那样做！
21、使用异常替代返回错误码
22、抽离 Try/Catch 代码块
它们搞乱了代码结构，把错误处理与正常流程混为一谈。
最好把 try 和 catch 代码块的主体部分抽离出来，另外形成函数。
网友评论