java开发规范

参考以下两个，取其最基本的规范

Google Java编程风格指南：http://www.hawstein.com/posts/google-java-style.html

阿里JAVA编码规范手册：

https://wenku.baidu.com/view/d3710b2a6fdb6f1aff00bed5b9f3f90f76c64d2a.html?from=search

 

(一)命名规范

 

1.【强制】类名使用 UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：（领域模型 的相关命名）DO / BO / DTO / VO等。 

正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion

反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

 

2.【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase风格，必须遵从 驼峰形式。

正例： localValue / getHttpMessage() / inputUserId

 

3.【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

正例： MAX_STOCK_COUNT 反例： MAX_COUNT

 

4.【强制】杜绝完全不规范的缩写，避免望文不知义。  反例： AbstractClass“缩写”命名成 AbsClass；condition“缩写”命名成 condi，此类 随意缩写严重降低了代码的可阅读性

 

5.【参考】枚举类名建议带上 Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。 说明：枚举其实就是特殊的常量类，且构造方法被默认强制是私有。  正例：枚举名字：DealStatusEnum，成员名称：SUCCESS / UNKOWN_REASON。

 

(二)格式规范 

1.【强制】大括号的使用约定。

如果是大括号内为空，则简洁地写成{}即可，不需要换行；

如果 是非空代码块则：

1） 左大括号前不换行。

2） 左大括号后换行。

3） 右大括号前换行。 

4） 右大括号后还有 else等代码则不换行；

表示终止右大括号后必须换行。

 

2.【强制】空行，不要突然空出两三行

 

3.【推荐】if else 不要超过三层

           反例：if(){

                                if(){

                                           if(){

(三)注释规范 

1.【强制】类、类属性、类方法的注释必须使用 Javadoc规范，使用/**内容*/格式，不得使用 //xxx方式。 

说明：在 IDE编辑窗口中，Javadoc方式会提示相关注释，生成 Javadoc可以正确输出相应注 释；在 IDE中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高 阅读效率。 

 

2.【强制】所有的抽象方法（包括接口中的方法）必须要用 Javadoc注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能。

说明：对子类的实现要求，或者调用注意事项，请一并说明。

 

3.【强制】所有的类都必须添加创建者信息，时间，备注。 

 

4.【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐。 

 

5.【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。

 

6【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持 英文原文即可。  反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。

 

7.【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑 等的修改。  说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后， 就失去了导航的意义。

 

8【参考】注释掉的代码尽量要配合说明，而不是简单的注释掉。  说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没 有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。

 

9.【参考】对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。 

 

10.【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的 一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

反例：  // put elephant into fridge put(elephant, fridge);  方法名 put，加上两个有意义的变量名 elephant和 fridge，已经说明了这是在干什么，语 义清晰的代码不需要额外的注释。

11. 【推荐】在原有代码上的改动 加上注释 类似 xj add/update/delete 20180319 v1.8.0 xxxxxxx

 

12.【推荐】给别人提供接口，要在接口入口和返回处加上日志方便联调，特别是dubbo调用

(四)代码实现规范

1.【强制】Object的 equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用  equals。  正例： "test".equals(object); 反例： object.equals("test");

 

2.【推荐】循环体内，字符串的连接方式，使用 StringBuilder的 append方法进行扩展。 反例：  String str = "start";

 for (int I = 0; I < 100; i++) {

 str = str + "hello";

 } 

说明：反编译出的字节码文件显示每次循环都会 new出一个 StringBuilder对象，然后进行  append操作，最后通过 toString方法返回 String对象，造成内存资源浪费

 

3.【推荐】集合初始化时，尽量指定集合初始值大小。

说明：ArrayList尽量使用 ArrayList(int initialCapacity) 初始化。

 

4.【强制】对枚举值的引用不允许直接写值，必须通过常量引用

           反例：1.carInfo.setState(2);

                       2.throw new BizException(100);

 

5.【推荐】只要是合法的，就把@Override注解给用上。

 

6.【强制】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低。

 

7.【强制】不要对大段代码进行 try-catch。catch时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch尽可能进行区分异常类型，再做对应的异常处理。

 

8.【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请 将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。

 

9.【强制】redis更新和mq消息发送放在事物最后执行，因为他们不能回滚

 

10.【强制】涉及第三方接口的操作，不要和数据库事物代码放在一个事物里，因为第三方接口返回时间不能保证，会增加数据库锁定的时间

 

11.【推荐】公共的工具类或服务类尽量统一抽取，减少维护成本

 

(五)数据库规范

1.【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造 成死锁。  说明：线程一需要对表 A、B、C依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序 也必须是 A、B、C，否则可能出现死锁

 

2.【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。 说明：1）增加查询分析器解析成本。2）增减字段容易与 resultMap配置不一致。

 

3.【推荐】不要写一个大而全的数据更新接口，传入为 POJO类，不管是不是自己的目标更新字 段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL 时，尽量不要更新无改动的字段，一是易出错；二是效率低；三是增加 binlog存储。

 

4.【推荐】xml里自动生成的sql语句，没有必要的就删掉，后期增加字段时会增加维护成本

 

5.【强制】上线的sql脚本可以重复执行不报错

 

(六)流程规范

1.【推荐】没有在上线计划的改动要邮件通知测试人员

2.【强制】代码本地要自测