Java编码规范建议

jopen 7年前

编码规范建议

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

 

1、重复代码

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

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

 

2、过长函数

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

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

 

3、过大的类

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

 

4、过长参数列表

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

 

5、发散式变化

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

 

6、散弹式修改

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

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

 

7、依恋情结

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

 

8、数据泥团

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

 

9、基本类型偏执

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

 

10Switch

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

 

11、冗赘类

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

 

12、夸夸其谈未来性

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

 

13、暂时字段

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

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

 

14、过度耦合的消息链

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

 

15、中间人

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

 

16、异曲同工类

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

 

17、过多的注释

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

 

 

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

 

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