java代码参考规范

一、命名规约

1.代码中的变量命名一律不允许以下划线或美元符号开头或结尾。

• 反例：_name/name_/$name/name$

2.代码中的命名禁止使用汉语拼音和英文混合的方式，纯拼音的方式也尽量不用， 除非特殊情况请给出注释。某些国际通用的名称如alibaba/youku/beijing等可视为英文，但是如QQ等一律使用小写qq命名。

• 反例：getPingfenByName()

3.包的命名一律以com.bw开头，包名一律使用小写，点分隔符之间有且仅有一个自然语义的单词，不能包含特殊字符。包的划分要详细清晰，不要怕多。

4.类名使用UpperCamelCase风格（首字母大写），遵从驼峰形式。

• 正例：UserService

• 反例：userService/XMLService

5.方法名、变量名使用LowerCamelCase风格（首字母小写），遵从驼峰形式。

• 正例：getUsers()/enterUserId

6.类的命名尽量加上某些前缀或后缀以明确表达该类的功能，如果不能明确,切不可乱加前后缀。

• 前缀
• • 前缀

  前缀名	描述	举例
  Abstract	抽象类	AbstractBeanFactory
  Base	基础类（提供常用方法）	BaseDao
  Default	默认类(对某接口的默认实现)	DefaultAopProxyFactory

  • 后缀

  后缀名	描述	举例
  Service	表明这个类是个服务类，里面包含了给其他类提同业务服务的方法	PaymentOrderService
  Impl	这个类是一个实现类，而不是接口	PaymentOrderServiceImpl
  Dao	这个类封装了数据访问方法	PaymentOrderDao
  Listener	响应某种事件的类	PaymentSuccessListener
  Action	直接处理页面请求，管理页面逻辑了类	UpdateOrderListAction
  Filter	这个类是过滤器	EncodingFilter
  Event	这个类代表了某种事件	PaymentSuccessEvent
  Servlet	一个Servlet	PaymentCallbackServlet
  Factory	生成某种对象工厂的类	PaymentOrderFactory
  Adapter	用来连接某种以前不被支持的对象的类	DatabaseLogAdapter
  Job	某种按时间运行的任务	PaymentOrderCancelJob
  Wrapper	这是一个包装类，为了给某个类提供没有的能力	SelectableOrderListWrapper
  Bean	这是一个POJO	MenuStateBean
  Exception	异常类	ErrorParametersException

  7.常量命名要全部大写，单词间用下划线分隔，要求语义表达完整，不要嫌名字长。

  8.数组定义一律采用String[] args这种方式，不可使用String args[]的定义方式。

  9.POJO类中布尔类型的变量不要加is，否则部分框架解析会引起序列化错误。

  • 正例：boolean success
  • 反例：boolean isSuccess

  10.每一个POJO类要给出toString()方法，便于打印日志或者查找bug。

  11.接口类中的方法不要加任何修饰符号，保持代码简洁性。尽量不要在接口中定义变量。

  • 正例：void sayHello()

  • 反例：public void sayHello()

  12.枚举类名建议带上Enum后缀，枚举成员名称要全部大写，单词间用下划线隔开。

  • 正例：枚举类名：DealStatusEnum,成员名称:SUCCESS / UNKNOWN_REASON

  13.Service/Dao层方法命名规约：

    1) 获取单个对象用get做前缀；

    2) 获取多个对象用list做前缀；

    3) 获取统计值的方法用count做前缀；

    4) 插入方法用save或insert做前缀；

    5) 删除方法用remove或delete做前缀；

    6) 修改方法用update做前缀。

  14.long或者Long类型赋值时，必须使用大写的L，不能使用小写的l，避免和数字1造成混淆。

  • 正例：Long a = 2L
  • 反例：Long a = 2l

  15.不要使用一个常量类来维护所有的常量，如果常量过多不利于维护。应该按照常量的功能进行分类，分开定义和维护。比如与缓存相关的常量定义在CacheConsts下；系统配置相关的常量定义在ConfigConsts下。

  16.杜绝不规范的缩写，避免望文不知义。

  • 反例：AbstractClass缩写为AbsClass，此类随意的缩写会严重降低代码的可阅读性

  二、格式规约

  1.大括号的使用约定：如果大括号内为空，则直接间接的写成{}，不需要换行；如果是为空代码块，则：

    1) 左大括号前不换行，左大括号后换行；

    2) 右大括号前换行；

    3) 右大括号后还有else等代码则不换行。

  2.左括号与后一个字符之间不加空格，右括号与前一个字符之间不加空格。

  3.if/for/while/switch/do等关键字与左右括号之间加空格。

  4.任何一个运算符左右两边加空格。

    说明：运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号、三目运算符等。

  5.单行字符数不宜超过120个，超出则需要换行，换行是遵循以下规则：

    1) 第二行相对于第一行缩进4个空格，从第三行开始不在继续缩进；

    2) 运算符与下文一起换行；

    3) 方法调用的点号与下文一起换行；

    4) 多个参数超长，在逗号后进行换行；

    5) 在括号前不要换行

  • 正例：

     StringBuffer sb = new StringBuffer();

     sb.append(“a”).append(“b”)...

       .append(“c”)...

       .append(“d”);

  • 反例：

     StringBuffer sb = new StringBuffer();

     sb.append(“a”).append(“b”)...append

       (“c”);

  6.IDE中的text file encoding 设置为UTF-8。

  7.建议方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同的业务逻辑和语义之间不需要插入空行。

  8.每个文件不超过2000行，避免将所有方法放到一个类中，影响问题查找和代码阅读。

  三、编码规约

  1.不要通过一个类的对象来访问该类的静态变量或静态方法，直接通过类名访问即可。

  2.不要使用过时的类或者方法。

    说明：java.net.URLDecoder 中的decode(String encodeStr)方法已经过时，应该使用decode(String source,String encode)方法。

  3.Object的equals方法容易产生NPE问题，应该使用常量或者确定有值的对象来调用equals。

  • 正例：”test”.equals(object)

  • 反例：object.equals(“test”)

     说明：推荐使用java.util.Objects#equals（JDK7引入的工具类）

  4.所有包装类对象之间值的比较全部使用equals方法。

  5.基本数据类型与包装类型的使用标准如下：

    1) 所有的POJO类属性必须使用包装类型；

    2) RPC接口的返回值和参数必须使用包装类型；

    3) 方法中所有的局部变量使用基本数据类型。

  6.构造方法里面不要加入任何业务逻辑，如果有业务逻辑，放到init方法中。

  7.当一个类中有多个构造方法或者同名方法时，按照顺序放置在一起，便于阅读。

  8.类方法应最小化访问权限。

    说明：能用protected的就不要用public。不要将所有的方法都设为public。

  9.循环体内的字符串连接使用StringBuilder的append方法。

  10.对集合List循环遍历之前，除非明确该集合肯定不为空，否则一定要做非空判断。

  11.不要在foreach循环里进行元素的remove/add操作。remove元素请使用Iterator方式，如果并发操作，需要对Iterator对象加锁。

  12.使用entrySet遍历Map类集合KV，而不是keySet方式进行遍历。

  13.利用Set元素唯一的特性，可以快速对一个集合进行去重操作，避免使用List的contains方法进行遍历、对比、去重操作。

  14.在switch块内，每一个case要么通过break/return等来终止，要么注释说明程序将执行到哪个case为止；每一个switch都必须包括default并且放在最后，即使什么代码也没有。

  15.条件语句都必须使用大括号，即使只有一行代码，避免使用单行的形式。 \

  • 反例：if ( condition ) statements

  16.表达异常的分支时，少用if-else方式，这种方式可以改写成：

    If(condition) {

      ......

      return obj;

    }

    //接着写else的业务逻辑代码

    说明：如果非要使用if()...else if()...else...方式表达逻辑，不要超过3层，避免代码维护困难。

  17.条件判断中不要执行过于复杂的语句，将复杂逻辑判断赋值给一个有意义的布尔变量名，以提高可读性。

  18.循环体内的语句要注意考量性能，比如定义对象、变量、获取数据库连接、进行不必要的try-catch操作等尽量移至循环体外处理。

  19.在类、类属性、类方法的注释必须使用javadoc规范，即使用/*内容/格式，不得使用//XXX的方式。

  20.所有的抽象方法（包括接口中的方法）都必须用javadoc注释，并且说明该方法的功能。

  21.方法内部单行注释，在被注释语句上方另起一行，用//注释；多行注释使用/* */注释，与代码对齐。

  22.代码修改的同时，也要修改相应的注释，避免代码已经修改了多版，但注释还是第一版，导致注释与代码严重不符。

  23.建议任何数据结构的构造或初始化，指定初始化大小。

  24.不要尝试通过异常来进行流程控制，条件控制，因为异常的处理效率比条件分支低。

  25.不要对大段代码进行try-catch。要尽量分清稳定代码和非稳定代码。

  26.捕获到异常不要什么都不做，如果不想处理它，请向上抛出。

  27.不能在finally块中使用return，finally块中的return返回后方法结束，不会再执行try块中的return语句。

  28.方法如果返回null时，要特别注释说明什么情况下会返回null，调用者需要进行非空判断防止NPE问题。

  29.避免出现大量重复性的代码。

  30.在方法的有效输入、输出和关键位置要打印有意义的日志，对于问题的排查有好处。打印日志请使用log.info()，避免使用System.out.println()。

  31.数据库中小数类型为decimal，不要使用float和double。

    说明：float和double在存储的时候存在精度损失的问题，很可能在值的比较时得不到正确的结果。

  32.代码中涉及到小数的运算时，尤其是跟钱有关时，一定要使用BigDecimal进行操作，否则会造成精度缺失，数据错误。

  33.方法的参数不宜过多，当超过6个参数时，应将参数封装成一个类来使用。

  34.异常的捕获或者抛出不要都使用java.lang.Exception，要对具体的异常进行细分。

  35.方法中的参数不要在方法体内对其进行重新赋值，要想使用方法中的变量值，要重新定义变量进行赋值。

  36.同一行中不要声明多个变量。

  • 正例：int a=0;

        Int b=1;

  • 反例：int a=0;b=1;

  37.复写的方法一定要加@Override注解。

  38.Pojo类中的成员变量不要定义默认值。

  39.一个类中的各个组件定义顺序如下：

    静态变量->私有变量->构造方法->公有方法->保护方法->私有方法->set/get方法

  40.重写equals方法的同时要重写hashCode方法。