编码规范建议

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员  --Martin Flower

 

1、重复代码

      如果在一个以上的地方看到相同的程序结构，那么设法将它们合而为一，程序会变得更好。

    将大的函数拆分成小的方法，可以在一定程度上减少代码重复，提高代码利用率。

 

2、过长函数

      应该积极地分解函数。每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。

       定义的变量名称，方法名称，类名称以及JSP名称等应该具有一定的意义。不要定义类似a1，a2，abc…这类没有意义或意义不明显的变量。

 

3、过大的类

      如果想利用单个类做太多的事情，其内往往就会出现太多实例变量。一旦如此，重复代码问题也就接踵而至了。应该按职能的不同将其细化为多个小类或子类。

 

4、过长参数列表

      太长的参数列表难以理解，而且容易造成前后不一致，不易使用。应该将对象传递给函数，你只需要在函数内调用getXXX方法，就能得到更多数据。

 

5、发散式变化

如果某个类因为不同的原因在不同的方向上发生变化，发散式变化便产生了。应该在不同方向上将其拆分为不同的子类。

 

6、散弹式修改

      如果每遇到某种变化，你都必须在许多不同的类内做许多小修改，你所面临的问题就是散弹式修改。应该把所有需要修改的代码放进同一个类中，使得“外界变化”与“需要修改的类”趋于一一对应。

      对于可以引起修改的地方，应该集中在某个地方，而不要到处乱放。（例如：实例里面Bean中的获取Request参数方法）

 

7、依恋情结

      函数对某个类的兴趣高过对自己所处类的兴趣。如果一个函数内的大部分操作需要调用其他类的操作，应该将这个函数移至其他类中。

 

8、数据泥团

      如果常常可以在很多地方看到相同的三四项数据（如：两类中相同的字段、许多函数签名中相同的参数）。应该将这些数据项提炼到一个独立的对象中。

 

9、基本类型偏执

      如果需要使用多个基本类型表达一个数据组或数据结构的概念，那么应该将这些基本类型组合成小的对象。

 

10、Switch

      面向对象程序的最明显的特性就是：少用switch语句。应该使用面向对象中的多态概念解决此类问题。

 

11、冗赘类

      如果一个类的存在没有价值，就应该将其删除。

 

12、夸夸其谈未来性

      如果一个类是为了未来的需要而设置的，暂时用不到，你应该将其移去。

 

13、暂时字段

      如果某个实例变量仅为某种特定情况而设（例如为了某个特定算法的需要），这样的代码让人不易理解。应该新建一个类，将这个变量和与这个变量相关的代码都放进这个类中。

       在变量使用前定义变量，而不要再方法一开始就定义一大堆变量。

 

14、过度耦合的消息链

      如果一个对象的请求需要通过一系列的消息链转发，这时，一旦对象间的关系发生任何变化，客户端就不得不做相应的修改。

 

15、中间人

      如果一个类接口有一半的函数都委托给了其他类，这样就是过度运用了委托。应该直接和真正负责的对象打交道。

 

16、异曲同工类

      如果两个函数做同一件事，却有着不同的签名，则这两个类属于异曲同工类。应该根据它们的用途重新命名，并进行必要的划分。

 

17、过多的注释

      对应糟糕的代码，不应以大量的注释来弥补。

 

 

18、在方法体内，如果该方法有参数，强烈建议对参数的有效性和合法性进行检验，以避免类型空指针异常等低级BUG。

 

19、建议在BEAN方法内重写toString()方法，以提供更好的对象信息展示。