让代码更整洁

 

让代码更整洁

         我目前开始接触比较大的项目时，发现代码越写越乱。当几个人合作写一个项目时，可能会出现这个人写的代码，那个人看不懂，导致项目进展很不顺利的情况。所以我听了老师讲的有关提高代码质量的讲解后，自己又查询了有关资料，对于如何使代码更加整洁，更加容易让别人读懂做了一些整理和总结。

         在查阅资料的过程中，我越发体会到代码整洁的重要性。当几个人一起写程序，结果由于彼此写的代码都很难读懂，那么就要花很长时间去研究，看懂别人写的代码的意思，项目进度会变慢。写得不好的代码，在修改的时候，发现修改了一处后，发现有好几个地方需要同时修改。修改了一个BUG后，发现出来更多BUG。最后项目可能终于磕磕碰碰地完成了，后期维护的时候换了一批人来，他们发现这些代码很难读懂，最后他们提出要求，要重写代码。所以代码的整洁不光是关乎开发效率，更关乎代码的生命。下面我归纳了一下，从几个方面来提高代码的质量。

命名

命名十分重要，因为好的命名容易让人读懂，坏的命名读起来则会十分吃力。要注意用好的命名，在命名时仔细思考，如果发现更好的命名，可以及时将已有的命名更换。

1. 命名要名副其实。一个好的命名无需注释，别人一看这个命名就知道是什么意思。

int d;//消逝的时间，以日计

 

 

d是不确定什么意思的

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModifiction;
int fileAgeIndays;

 

 

就更容易理解和区分。

有时一段代码本身并不长，但是难以理解，这不是由于代码的复杂的，而是由于代码的模糊度。所以要准确地命名，让代码准确表达它的意义。

2.   避免误导。

（1）不要使用hp，aix和sco作变量名，因为它们是UNIX或类UNIX平台专用的名称。

（2）别用accountList来指称一组账号，除非它真是List类型。List对程序员有着特殊的意义。用accountGroup会更好一点。

（3）不要用相似度很大的命名，会很难区分，引起误解。

（4）不要用废话。如有一个Product类，另外有两个ProductInfo类和ProductData类，它们的名称虽然不同，但是表达的意思却是一样的。theMessage和Message也没有区别。这样不体现差别的命名时没有必要的。要区分就要以读者能理解的方式来区分。

（5）命名要便于搜索。单字母名称和数字常量在一大堆文字中很难被找到，所以长一点的命名好于短命名。MAX_CLASS_PER_STUDENT就比数字7更容易找到。并且名称的长短应和作用域的大小相对应。如果在短作用域内，则用短命名，在大作用域内则用长命名，以便它被找到。

3.类的命名

类名和对象名应该是名词或者名词短语。如Customer，Wikipage，Account等。避免使用Manager，Processor，Data或Info这样的类名，类名不应是动词。

4．方法名。

（1）方法名应当是动词或动词短语。如PostPayment，deletePage或save。属性的访问器，修改器和断言应该根据其值命名，并依Javabean标准加上get，set和is前缀。

（2）别使用双关。一个单词有多种意思就会难以理解。例如，有好几个类里面有add()方法，如果这些方法的参数列表，返回值都相同，那么就没有问题。但是如果不同，就出现了双关，如这个类里面的add()方法是表示两个现存的数值相加得到另一个新的数值，在另外一个类里add()的方法表示把单个参数放到群集中，这样的话，后面的一种情况用insert()会更好。

（3）使用长而由描述性的方法名，比不清楚的方法名加上长的注释更好。

方法

         （1）方法的第一原则是短小，更短小。

         （2）一个方法只做一件事，并且把这件事做好。判断一个方法是否只做了一件事的一个方法是看这个方法是否还可以被拆分。如果一个方法只做一件事，它是无法被合理拆分的。

         （3）一个方法只能有一个抽象层。代码要拥有自顶向下的阅读顺序，每个方法后面都跟着位于下一个抽象层级的方法。这叫向下原则。这个可能不太好理解，用一个例子可以说明这种思想。阅读下面几句话，体会其中包含的逻辑关系。

To include the setups and teardowns, we include setups, then we include the test page content, and then we include the teardowns.（要容纳设置和分析步骤，就先容纳设置步骤，然后容纳测试页面内容，再纳入分拆步骤）

To include the suit setups, we include the suit setup, if this is a suit, then we include the regular setup.（要容纳设置步骤，如果是套件，就纳入套件设置步骤，然后纳入普通设置步骤）

To include the suit setup, we search the parent hierarchy for the “SuitSetUp” page and add an include statemaent with the path of that page.（要容纳套件设置步骤，先搜索”SuitSetUp”页面的上级继承关系，再添加一个包括该页面路径的语句）

To search …（要搜索…）

         （4）方法参数尽量少，参数越多就越难读懂。如果方法的参数有两个，三个或者三个以上，就应该用一个类来封装这些参数。

注释

         首先对注释的态度，应该先端正。我之前认为一个好的代码应该是注释很详细的，但是我查考了相关资料后却不这么认为了。注释并非越多越好。注释是为了弥补代码的缺陷。如果代码本身是垃圾代码，那么再好的注释都不能美化它。

//Check to see if the employee id eligible for full benefits
if((employee.flag & HOURLY_FLAG) && (employee.age > 65))

 

 

和

if(employee.isEligibleForBenefits())

 

 

哪个更容易读懂呢？

所以当代码本身很差时，与其花时间去写好的注释，不如花时间去重新写一个更好的代码。

         话虽如此，一个好的注释还是有必要的。一个好的注释有很多要求，我根据我的目前水平，整理了一些条件。

（1）法律信息。如版权著作权声明等就必须在每个源文件开头注明。

（2）提供信息的注释。如对一个方法返回值的解释。

（3）对意图的解释。

（4）阐释。对某些比较难懂的参数或者返回值进行翻译，让其更容易读懂。当然最好的方法是让参数或者返回值本身就容易读懂。但是如果参数或者方法是某个标准库的一部分，或者是不能修改的代码，那么阐释其含义就是很有用的。

（5）警示。用语警告其他程序员会出现某种后果的注释也是有用的。

以上是一些好的注释的例子。那么我们平时也有可能写一些坏注释，我们应该如何避免呢？

         通常的坏注释有以下一些类型。

（1）喃喃自语和循规式的注释。有时写一些注释仅仅是因为你觉得要需要或者由于那些认为每个变量都应该有注释的规矩而写注释是没有必要的。因为有些时候变量名本身意思很明了，那么就不需要写注释了。

（2）多余的注释。如果代码块本身的意思非常清楚，那么就没有必要写非常详细的注释。写多余的详细的注释反而会妨碍阅读。

（3）误导性的注释。如果注释没有准确地表达意思，是意思有偏差，那么就会让使用者误解，使用错误。

错误处理

（1）在异常处理中不要反悔null更不要传递null，如果返回或者传递了null，那么如果在使用这个方法时没有检验null，就会报空指针异常。

（2）异常是抛出或者自己处理的选择。如何类自己有能力处理这个异常，那么就可以自己处理，如果不能则抛出。所谓有能力就是指如果这个方法自己处理了这个异常，返回的值还是这个方法承诺的，那么就说明这个方法有能力处理这个异常。方法的调用是一个职责链，切忌出现了错误却不知道错在哪里。

 

由于目前的实力有限，我的整理就到这里。我们都想写出整洁高质量的代码。但是在第一次写的时候就能写出非常整洁的代码是非常困难的，我想哪怕一个人实力再强，要想做到这样还是困难。整洁的代码与其说是写出来的，不如说是改出来的。在写完一段代码后，对代码进行优化，使其更加整洁。

 

参考文献

Robert C.Martin，韩磊译. 代码整洁之道 [M]. 人民邮电出版社，2010