《代码整洁之道》

1、前言

让营地比你来的时候更干净

上面是美国童子军的军规，对于软件开发来说，如果每次检入都比检出的时候干净，那么代码将永远不会变的更坏。

2、命名

在程序开发的各个环节，命名是无处不在的。比如文件夹名、文件名、类名、方法名、变量名等等。

2.1、命名特点

好的命名应该遵循如下特点：

• 见名知意，这个也是我自己一贯坚持的原则。
• 不要使用过于简化的命名。有些简化是世界通用的，有些简化可能是某个编程人员自己的习惯，时间一长，自己看了都会费解，别人看更是如此。
• 避免误导。例如使用【o】【0】、【l】【1】等。当然个人感觉，这个只能说尽量吧，很多时候无法完全不用字母【o】【l】。
• 名字要读的出来。这个确实很有意思，而我平时也不大注意这点。因为读不出来的名字交流起来是极不方便的。

2.2、类

类和对象的名字应该是名词或名词短语。如User、Account。我想可能这个更契合OOP的理念吧，每个类都应该是一个抽象的物体。

应当避免使用Manager、Info这样的类名

其实我自己非常喜欢用Manager这样的后缀，在看到这句话的时候，我在想这是为什么？

后来我在看到【单一职责原则】的时候，想到用Manager是否意味着这个类承担了过多的职责，这个类耦合度过高了？

2.3、方法名

方法名应该使用动词或动词短语，如deletePage、getName等。
属性修改器、断言应根据其值命名，并依据javabean标准，加上get、set、is前缀。

3、函数

3.1、函数长度

短小

用原作者的话，是20行封顶最佳。当然我觉得是不是有点夸张，但大于100行的函数肯定不是一个好的函数。我在O’Relly的《代码不朽》一书中，看到的建议是尽量在65行以内，我觉得这个实现起来更容易一些。

如何能控制函数的长度？原则就是函数只做一件事，如果要求函数只做一件事，那么函数内所有语句的抽象层级就要一样高。这个抽象层级有点玄的味道，我感觉和之前看的《软件需求建模分析》一书中提到的流程图的级别的理念很类似。

我最初设计流程图的时候，做的比较乱，因为我把公司级流程、部门级流程、岗位级流程混在一起设计。这样的流程图庞大无比，可读性非常糟糕，而且不同级别的人关注的点，其实是不一样的。后来我将流程按级别分为L1、L2、L3等不同的级别，每个高级别的流程，在有子流程，这样看起来就直观很多。

因此我想，函数的抽象层次是不是也是这样，函数内的语句级别要一样。

3.2、函数参数

• 最理想的是零参数
• 其次是一个参数
• 再其次是二个参数
• 避免三个及三个以上的参数，这么多参数，意味着有些参数应该封装成类了。

3.3、别重复

重复可能是软件中一切邪恶的根源

遇到重复的代码，务必要封装。

4、注释

最好的注释是不用注释，如果程序有足够的表达力，不需要注释。

当然上面的话，我不完全认同。甚至整篇关于注释的章节，我很多地方是不认同的。

不认同的观点：

• 不需要文件头部的版权、法律信息。
• 不需要TODO注释。
• 不要编辑日志的注释。虽然代码管理工具能提供一些信息，但肯定无法记录如此详细的信息。

认同的观点：

• 废弃的代码不应注释掉，而是直接删除。尤其是在交付的产品中。
• 废弃的注释应尽快删除。

5、代码格式

5.1、垂直格式

• 代码文件的行数应该在200~500行范围内。
• 垂直方向的间隔
• 头文件、函数间、逻辑快间应该用空白行区隔。
• 垂直方向上的靠近
• 紧密联系的代码，应该在一块。
• 变量应该在申明后，就马上使用。
• 相关函数应该在一起，通常是被调用的函数，紧跟在执行调用函数的下面。

5.2、水平格式

• 每行代码的应控制在120个字符以下，从数据分析上来看，绝大部分程序员喜欢短代码行。
• 适当的使用空格，以分割代码。如method(paraA, paraB)
• 在循环或者分支语句中使用缩进。

5.3、团队规则

每个程序员都有自己喜欢的规则，但在一个团队工作中。一组开发者应当认同同一种格式风格。