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 代码块的主体部分抽离出来,另外形成函数。