编程规约

命名规约：

代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
命名必须以英文。
类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外：（领域模型
的相关命名）DO / BO / DTO / VO 等。
抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。
POJO 类中布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。

常量规约

long 或者 Long 初始赋值时，必须使用大写的 L，不能是小写的 l，小写容易跟数字1混淆，造成误解。
不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护。如：缓存相关的常量放在类：CacheConsts 下；系统配置相关的常量放在类：ConfigConsts 下。

OOP规约

相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object。
说明：可变参数必须放置在参数列表的最后。（提倡同学们尽量不用可变参数编程）
接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。
不能使用过时的类或方法。
所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。
说明：对于 Integer var=?在-128 至 127 之间的赋值，Integer 对象是在
IntegerCache.cache 产生，会复用已有对象，这个区间内的 Integer 值可以直接使用==进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，强制使用 equals 方法进行判断。
关于基本数据类型与包装数据类型的使用标准如下：
1）所有的 POJO 类属性必须使用包装数据类型。
2） RPC 方法的返回值和参数必须使用包装数据类型。
3）所有的局部变量【推荐】使用基本数据类型。
序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败；如
果完全不兼容升级，避免反序列化混乱，那么请修改 serialVersionUID 值.
构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。
【推荐】setter 方法中，参数名称与类成员变量名称一致，this.成员名=参数名。在
getter/setter 方法中，尽量不要增加业务逻辑，增加排查问题的难度。
【推荐】循环体内，字符串的联接方式，使用 StringBuilder 的 append 方法进行扩展。
【推荐】final 可提高程序响应效率，声明成 final 的情况：
1）不需要重新赋值的变量，包括类属性、局部变量。
2）对象参数前加 final，表示不允许修改引用的指向。
3）类方法确定不允许被重写。

集合处理

关于 hashCode 和 equals 的处理，遵循如下规则：
1）只要重写 equals，就必须重写 hashCode。
2）因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的
对象必须重写这两个方法。
3）如果自定义对象做为 Map 的键，那么必须重写 hashCode 和 equals。
正例：String 重写了 hashCode 和 equals 方法，所以我们可以非常愉快地使用 String 对象
作为 key 来使用。
不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator
方式，如果并发操作，需要对 Iterator 对象加锁。
-【推荐】使用 entrySet 遍历 Map 类集合 KV，而不是 keySet 方式进行遍历。

控制语句

在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使它什么代码也没有。
在 if/else/for/while/do 语句中必须使用大括号，即使只有一行代码，避免使用
下面的形式：if (condition) statements;
【推荐】推荐尽量少用 else。
说明：如果非得使用 if()…else if()…else…方式表达逻辑，【强制】请勿超过 3 层，超过请使用状态设计模式。

【推荐】除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。

正例：
//伪代码如下
boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
	if (existed) {
 		...
	} 
反例：
	if ((file.open(fileName, "w") != null) && (...) || (...)) {
	 ...
	}

【参考】方法中需要进行参数校验的场景：
1）调用频次低的方法。
2）执行时间开销很大的方法，参数校验时间几乎可以忽略不计，但如果因为参数错误导致中间执行回退，或者错误，那得不偿失。
3）需要极高稳定性和可用性的方法。
4）对外提供的开放接口，不管是 RPC/API/HTTP 接口。
5）敏感权限入口。
【参考】方法中不需要参数校验的场景：
1）极有可能被循环调用的方法，不建议对参数进行校验。但在方法说明里必须注明外部参数检查。
2）底层的方法调用频度都比较高，一般不校验。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中，部署在同一台服务器中，所以 DAO 的参数校验，可以省略。
3）被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。

异常日志

异常处理

不要捕获 Java 类库中定义的继承自 RuntimeException 的运行时异常类，如：
IndexOutOfBoundsException / NullPointerException，这类异常由程序员预检查
来规避，保证程序健壮性。
```
    正例：if(obj != null) {...}
    反例：try { obj.method() } catch(NullPointerException e){...}
```
对大段代码进行 try-catch，这是不负责任的表现。catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。
不能在 finally 块中使用 return，finally 块中的 return 返回后方法结束执行，不
会再执行 try 块中的 return 语句。
-【推荐】方法的返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回 null 值。调用方需要进行 null 判断防止 NPE 问题。
说明：本规约明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败，运行时异常等场景返回 null 的情况。
【推荐】防止 NPE，是程序员的基本修养，注意 NPE 产生的场景：
1）返回类型为包装数据类型，有可能是 null，返回 int 值时注意判空。
反例：public int f(){ return Integer 对象}; 如果为 null，自动解箱抛 NPE。
2）数据库的查询结果可能为 null。
3）集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。
4）远程调用返回对象，一律要求进行 NPE 判断。
5）对于 Session 中获取的数据，建议 NPE 检查，避免空指针。
6）级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。

MySQL规约

ORM规约

在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。
说明：1）增加查询分析器解析成本。2）增减字段容易与 resultMap 配置不一致。
POJO 类的 boolean 属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。
说明：参见定义 POJO 类以及数据库字段定义规定，在 sql.xml 增加映射，是必须的。
不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。
【参考】@Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。