========================= JAVA代码 ========================
1 . 【强制】抽象类命名使用 Abstract 或 Base 开头 ； 异常类命名使用 Exception 结尾 ； 测试类命名以它要测试的类的名称开始，以 Test 结尾。
2 . 【强制】中括号是数组类型的一部分，数组定义如下： String[] args;
反例：使用 String args[] 的方式来定义。
3 . 【强制】 POJO 类中布尔类型的变量，都不要加 is ，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型 Boolean isDeleted； 的属性，它的方法也是 isDeleted() ， RPC框架在反向解析的时候，“以为”对应的属性名称是 deleted，导致属性获取不到，进而抛出异常。
4 . 【推荐】接口类中的方法和属性不要加任何修饰符号 （public 也不要加 ） ，保持代码的简洁性，并加上有效的 Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名： void f();
接口基础常量表示： String COMPANY = " alibaba " ;
反例：接口方法定义： public abstract void f();
5 . 【参考】各层命名规约：
A) Service / DAO 层方法命名规约
1 ） 获取单个对象的方法用 get 做前缀。
2 ） 获取多个对象的方法用 list 做前缀。
3 ） 获取统计值的方法用 count 做前缀。
4 ） 插入的方法用 save/insert 做前缀。
5 ） 删除的方法用 remove/delete 做前缀。
6 ） 修改的方法用 update 做前缀。
B) 领域模型命名规约
1 ） 数据对象： xxxDO ， xxx 即为数据表名。
2 ） 数据传输对象： xxxDTO ， xxx 为业务领域相关的名称。
3 ） 展示对象： xxxVO ， xxx 一般为网页名称。
4 ） POJO 是 DO / DTO / BO / VO 的统称，禁止命名成 xxxPOJO 。
6 . 【强制】 long 或者 Long 初始赋值时，使用大写的 L ，不能是小写的 l ，小写容易跟数字 1 混淆，造成误解。
说明： Long a = 2 l; 写的是数字的 21，还是 Long 型的 2?
7 . 【推荐】不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护。
说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
正例：缓存相关常量放在类 CacheConsts 下 ； 系统配置相关常量放在类 ConfigConsts 下。
8 . 【强制】避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。
9 . 【强制】所有的覆写方法，必须加@ Override 注解。
说明： getObject() 与 get 0 bject() 的问题。一个是字母的 O ，一个是数字的 0，加@ Override可以准确判断是否覆盖成功。另外，如果在抽象类中对方法签名进行修改，其实现类会马上编译报错。
10 . 【强制】相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object 。
说明：可变参数必须放置在参数列表的最后。 （ 提倡同学们尽量不用可变参数编程 ）
正例： public User getUsers(String type, Integer... ids) {...}
12 . 【强制】 Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals 。
正例：" test " .equals(object);
反例： object.equals( " test " );
说明：推荐使用 java . util . Objects # equals（JDK 7 引入的工具类 ）
13 . 【强制】所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。
说明：对于 Integer var = ? 在-128 至 127 范围内的赋值， Integer 对象是在IntegerCache . cache 产生，会复用已有对象，这个区间内的 Integer 值可以直接使用==进行
判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用 equals 方法进行判断。
14 . 关于基本数据类型与包装数据类型的使用标准如下：
1 ） 【强制】所有的 POJO 类属性必须使用包装数据类型。
2 ） 【强制】 RPC 方法的返回值和参数必须使用包装数据类型。
3 ） 【推荐】所有的局部变量使用基本数据类型。
说明： POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE 问题，或者入库检查，都由使用者来保证。
正例：数据库的查询结果可能是 null ，因为自动拆箱，用基本数据类型接收有 NPE 风险。
反例：比如显示成交总额涨跌情况，即正负 x %， x 为基本数据类型，调用的 RPC 服务，调用不成功时，返回的是默认值，页面显示为0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null值，能够表示额外的信息，如：远程调用失败，异常退出。
15 . 【强制】定义 DO / DTO / VO 等 POJO 类时，不要设定任何属性默认值。
反例： POJO 类的 gmtCreate 默认值为 new Date(); 但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
16 . 【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。
17 . 【推荐】 setter 方法中，参数名称与类成员变量名称一致， this .成员名 = 参数名。在getter / setter 方法中，不要增加业务逻辑，增加排查问题的难度。
反例：
public Integer getData() {
if (true) {
return this.data + 100;
} else {
return this.data - 100;
}
}
18 . 【推荐】循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展。
说明：反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象，然后进行append 操作，最后通过 toString 方法返回 String 对象，造成内存资源浪费。
反例：
String str = "start";
for (int i = 0; i < 100; i++) {
str = str + "hello";
}
19 . 【推荐】 final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字：
1） 不允许被继承的类，如： String 类。
2） 不允许修改引用的域对象，如： POJO 类的域变量。
3） 不允许被重写的方法，如： POJO 类的 setter 方法。
4） 不允许运行过程中重新赋值的局部变量。
5） 避免上下文重复使用一个变量，使用 final 描述可以强制重新定义一个变量，方便更好地进行重构。
20 . 【强制】使用集合转数组的方法，必须使用集合的 toArray(T[] array) ，传入的是类型完全一样的数组，大小就是 list . size() 。
说明：使用 toArray 带参方法，入参分配的数组空间不够大时， toArray 方法内部将重新分配内存空间，并返回新数组地址 ； 如果数组元素大于实际所需，下标为 [ list . size() ] 的数组元素将被置为 null ，其它数组元素保持原值，因此最好将方法入参数组大小定义与集合元素个数一致。
正例：
List<String> list = new ArrayList<String>(2);
list.add("guan");
list.add("bao");
String[] array = new String[list.size()];
array = list.toArray(array);
反例：直接使用 toArray 无参方法存在问题，此方法返回值只能是 Object[] 类，若强转其它类型数组将出现 ClassCastException 错误。
21 . 【强制】泛型通配符<? extends T >来接收返回的数据，此写法的泛型集合不能使用 add 方法，而 <? super T> 不能使用 get 方法，做为接口调用赋值时易出错。
说明：扩展说一下 PECS(Producer Extends Consumer Super) 原则：第一、频繁往外读取内容的，适合用<? extends T >。第二、经常往里插入的，适合用 <? super T> 。
22 . 【参考】利用 Set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 List 的contains 方法进行遍历、对比、去重操作。
23 . 【强制】 SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为static ，必须加锁，或者使用 DateUtils 工具类。
正例：注意线程安全，使用 DateUtils 。亦推荐如下处理：
private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
@ Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
24 . 【强制】在一个 switch 块内，每个 case 要么通过 break / return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止 ； 在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使它什么代码也没有。
25 . 【强制】在 if / else / for / while / do 语句中必须使用大括号。即使只有一行代码，避免采用单行的编码方式： if (condition) statements;
26 . 【推荐】表达异常的分支时，少用 if-else 方式 ，这种方式可以改写成：
if (condition) {
...
return obj;
}
// 接着写 else 的业务逻辑代码;
说明：如果非得使用 if()...else if()...else... 方式表达逻辑，【强制】避免后续代码维护困难，请勿超过 3 层。
正例：超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，
其中卫语句示例如下：
public void today() {
if (isBusy()) {
System.out.println(“change time.”);
return;
}
if (isFree()) {
System.out.println(“go to travel.”);
return;
}
System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);
return;
}
27 . 【推荐】除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
说明：很多 if 语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？
正例：
// 伪代码如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
反例：
if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}
28 . 【推荐】循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的 try - catch 操作 （ 这个 try - catch 是否可以移至循环体外 ） 。
29 . 【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用// xxx 方式。
说明：在 IDE 编辑窗口中， Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释 ； 在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
30 . 【强制】对大段代码进行 try - catch ，这是不负责任的表现。 catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。
31 . 【参考】避免出现重复的代码 （Don ’ t Repeat Yourself） ，即 DRY 原则。
说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。
正例：一个类中有多个 public 方法，都需要进行数行相同的参数校验操作，这个时候请抽取：
private boolean checkParam(DTO dto) {...}
32 . 【强制】对 trace / debug / info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式。
说明： logger . debug( " Processing trade with id : " + id + " and symbol : " + symbol);
如果日志级别是 warn ，上述日志不会打印，但是会执行字符串拼接操作，如果 symbol 是对象，会执行 toString()方法，浪费了系统资源，执行了上述操作，最终日志却没有打印。
正例： （ 条件 ）
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}
正例： （ 占位符 ）(推荐所有带参数的日志均用此种方式)
logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
33 . 【强制】避免重复打印日志，浪费磁盘空间，务必在 log 4 j . xml 中设置 additivity = false 。
正例： <logger name="com.taobao.dubbo.config" additivity="false">
34 . 【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。
正例： logger.error(各类参数或者对象 toString + "_" + e.getMessage(), e);
35 . 【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志 ； 有选择地输出 info 日志 ； 如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。 说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？
36 . 【参考】可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。注意日志输出的级别， error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必要，请不要在此场景打出 error 级别。
========================= MySql数据库 ========================
1 . 1. 【强制】表达是与否概念的字段，必须使用 is _ xxx 的方式命名，数据类型是 unsigned tinyint（ 1 表示是，0 表示否 ） 。
说明：任何字段如果为非负数，必须是 unsigned 。
正例：表达逻辑删除的字段名 is_deleted ，1 表示删除，0 表示未删除。
2 . 【强制】表名、字段名必须使用小写字母或数字 ， 禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。
正例： aliyun _ admin ， rdc _ config ， level 3_ name
反例： AliyunAdmin ， rdcConfig ， level _3_ name
3 . 【强制】禁用保留字，如 desc 、 range 、 match 、 delayed 等，请参考 MySQL 官方保留字
4 . 【强制】 varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text ，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
5 . 【推荐】单表行数超过 500 万行或者单表容量超过 2 GB ，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
6 . 【强制】不要使用 count( 列名 ) 或 count( 常量 ) 来替代 count( * ) ， count( * ) 是 SQL 92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。
说明： count( * ) 会统计值为 NULL 的行，而 count( 列名 ) 不会统计此列为 NULL 值的行。
7 . 【强制】当某一列的值全是 NULL 时， count(col) 的返回结果为 0，但 sum(col) 的返回结果为NULL ，因此使用 sum() 时需注意 NPE 问题。
正例：可以使用如下方式来避免 sum 的 NPE 问题： SELECT IF(ISNULL(SUM(g)) ,0, SUM(g))FROM table;
8 . 【强制】使用 ISNULL() 来判断是否为 NULL 值。
说明： NULL 与任何值的直接比较都为 NULL。
1 ） NULL<>NULL 的返回结果是 NULL ，而不是 false 。
2 ） NULL=NULL 的返回结果是 NULL ，而不是 true 。
3 ） NULL<>1 的返回结果是 NULL ，而不是 true 。
9 . 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
说明：以学生和成绩的关系为例，学生表中的 student _ id 是主键，那么成绩表中的 student _ id则为外键。如果更新学生表中的 student _ id ，同时触发成绩表中的 student _ id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群 ；
级联更新是强阻塞，存在数据库更新风暴的风险 ； 外键影响数据库的插入速度。
10 . 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
11 . 【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。
说明： resultClass=”Hashtable” ，会置入字段名和属性值，但是值的类型不可控。
12 . 【推荐】不要写一个大而全的数据更新接口。传入为 POJO 类，不管是不是自己的目标更新字段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL时，不要更新无改动的字段，一是易出错 ； 二是效率低 ； 三是增加 binlog 存储。
13 . 【参考】@ Transactional 事务不要滥用。事务会影响数据库的 QPS ，另外使用事务的地方需
要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
1 . 【强制】抽象类命名使用 Abstract 或 Base 开头 ； 异常类命名使用 Exception 结尾 ； 测试类命名以它要测试的类的名称开始，以 Test 结尾。
2 . 【强制】中括号是数组类型的一部分，数组定义如下： String[] args;
反例：使用 String args[] 的方式来定义。
3 . 【强制】 POJO 类中布尔类型的变量，都不要加 is ，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型 Boolean isDeleted； 的属性，它的方法也是 isDeleted() ， RPC框架在反向解析的时候，“以为”对应的属性名称是 deleted，导致属性获取不到，进而抛出异常。
4 . 【推荐】接口类中的方法和属性不要加任何修饰符号 （public 也不要加 ） ，保持代码的简洁性，并加上有效的 Javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名： void f();
接口基础常量表示： String COMPANY = " alibaba " ;
反例：接口方法定义： public abstract void f();
5 . 【参考】各层命名规约：
A) Service / DAO 层方法命名规约
1 ） 获取单个对象的方法用 get 做前缀。
2 ） 获取多个对象的方法用 list 做前缀。
3 ） 获取统计值的方法用 count 做前缀。
4 ） 插入的方法用 save/insert 做前缀。
5 ） 删除的方法用 remove/delete 做前缀。
6 ） 修改的方法用 update 做前缀。
B) 领域模型命名规约
1 ） 数据对象： xxxDO ， xxx 即为数据表名。
2 ） 数据传输对象： xxxDTO ， xxx 为业务领域相关的名称。
3 ） 展示对象： xxxVO ， xxx 一般为网页名称。
4 ） POJO 是 DO / DTO / BO / VO 的统称，禁止命名成 xxxPOJO 。
6 . 【强制】 long 或者 Long 初始赋值时，使用大写的 L ，不能是小写的 l ，小写容易跟数字 1 混淆，造成误解。
说明： Long a = 2 l; 写的是数字的 21，还是 Long 型的 2?
7 . 【推荐】不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护。
说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
正例：缓存相关常量放在类 CacheConsts 下 ； 系统配置相关常量放在类 ConfigConsts 下。
8 . 【强制】避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。
9 . 【强制】所有的覆写方法，必须加@ Override 注解。
说明： getObject() 与 get 0 bject() 的问题。一个是字母的 O ，一个是数字的 0，加@ Override可以准确判断是否覆盖成功。另外，如果在抽象类中对方法签名进行修改，其实现类会马上编译报错。
10 . 【强制】相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object 。
说明：可变参数必须放置在参数列表的最后。 （ 提倡同学们尽量不用可变参数编程 ）
正例： public User getUsers(String type, Integer... ids) {...}
12 . 【强制】 Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals 。
正例：" test " .equals(object);
反例： object.equals( " test " );
说明：推荐使用 java . util . Objects # equals（JDK 7 引入的工具类 ）
13 . 【强制】所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。
说明：对于 Integer var = ? 在-128 至 127 范围内的赋值， Integer 对象是在IntegerCache . cache 产生，会复用已有对象，这个区间内的 Integer 值可以直接使用==进行
判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用 equals 方法进行判断。
14 . 关于基本数据类型与包装数据类型的使用标准如下：
1 ） 【强制】所有的 POJO 类属性必须使用包装数据类型。
2 ） 【强制】 RPC 方法的返回值和参数必须使用包装数据类型。
3 ） 【推荐】所有的局部变量使用基本数据类型。
说明： POJO 类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE 问题，或者入库检查，都由使用者来保证。
正例：数据库的查询结果可能是 null ，因为自动拆箱，用基本数据类型接收有 NPE 风险。
反例：比如显示成交总额涨跌情况，即正负 x %， x 为基本数据类型，调用的 RPC 服务，调用不成功时，返回的是默认值，页面显示为0%，这是不合理的，应该显示成中划线。所以包装数据类型的 null值，能够表示额外的信息，如：远程调用失败，异常退出。
15 . 【强制】定义 DO / DTO / VO 等 POJO 类时，不要设定任何属性默认值。
反例： POJO 类的 gmtCreate 默认值为 new Date(); 但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
16 . 【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。
17 . 【推荐】 setter 方法中，参数名称与类成员变量名称一致， this .成员名 = 参数名。在getter / setter 方法中，不要增加业务逻辑，增加排查问题的难度。
反例：
public Integer getData() {
if (true) {
return this.data + 100;
} else {
return this.data - 100;
}
}
18 . 【推荐】循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展。
说明：反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象，然后进行append 操作，最后通过 toString 方法返回 String 对象，造成内存资源浪费。
反例：
String str = "start";
for (int i = 0; i < 100; i++) {
str = str + "hello";
}
19 . 【推荐】 final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字：
1） 不允许被继承的类，如： String 类。
2） 不允许修改引用的域对象，如： POJO 类的域变量。
3） 不允许被重写的方法，如： POJO 类的 setter 方法。
4） 不允许运行过程中重新赋值的局部变量。
5） 避免上下文重复使用一个变量，使用 final 描述可以强制重新定义一个变量，方便更好地进行重构。
20 . 【强制】使用集合转数组的方法，必须使用集合的 toArray(T[] array) ，传入的是类型完全一样的数组，大小就是 list . size() 。
说明：使用 toArray 带参方法，入参分配的数组空间不够大时， toArray 方法内部将重新分配内存空间，并返回新数组地址 ； 如果数组元素大于实际所需，下标为 [ list . size() ] 的数组元素将被置为 null ，其它数组元素保持原值，因此最好将方法入参数组大小定义与集合元素个数一致。
正例：
List<String> list = new ArrayList<String>(2);
list.add("guan");
list.add("bao");
String[] array = new String[list.size()];
array = list.toArray(array);
反例：直接使用 toArray 无参方法存在问题，此方法返回值只能是 Object[] 类，若强转其它类型数组将出现 ClassCastException 错误。
21 . 【强制】泛型通配符<? extends T >来接收返回的数据，此写法的泛型集合不能使用 add 方法，而 <? super T> 不能使用 get 方法，做为接口调用赋值时易出错。
说明：扩展说一下 PECS(Producer Extends Consumer Super) 原则：第一、频繁往外读取内容的，适合用<? extends T >。第二、经常往里插入的，适合用 <? super T> 。
22 . 【参考】利用 Set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 List 的contains 方法进行遍历、对比、去重操作。
23 . 【强制】 SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为static ，必须加锁，或者使用 DateUtils 工具类。
正例：注意线程安全，使用 DateUtils 。亦推荐如下处理：
private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
@ Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd");
}
};
24 . 【强制】在一个 switch 块内，每个 case 要么通过 break / return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止 ； 在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使它什么代码也没有。
25 . 【强制】在 if / else / for / while / do 语句中必须使用大括号。即使只有一行代码，避免采用单行的编码方式： if (condition) statements;
26 . 【推荐】表达异常的分支时，少用 if-else 方式 ，这种方式可以改写成：
if (condition) {
...
return obj;
}
// 接着写 else 的业务逻辑代码;
说明：如果非得使用 if()...else if()...else... 方式表达逻辑，【强制】避免后续代码维护困难，请勿超过 3 层。
正例：超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，
其中卫语句示例如下：
public void today() {
if (isBusy()) {
System.out.println(“change time.”);
return;
}
if (isFree()) {
System.out.println(“go to travel.”);
return;
}
System.out.println(“stay at home to learn Alibaba Java Coding Guidelines.”);
return;
}
27 . 【推荐】除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
说明：很多 if 语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？
正例：
// 伪代码如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
反例：
if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}
28 . 【推荐】循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的 try - catch 操作 （ 这个 try - catch 是否可以移至循环体外 ） 。
29 . 【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/**内容*/格式，不得使用// xxx 方式。
说明：在 IDE 编辑窗口中， Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释 ； 在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
30 . 【强制】对大段代码进行 try - catch ，这是不负责任的表现。 catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。
31 . 【参考】避免出现重复的代码 （Don ’ t Repeat Yourself） ，即 DRY 原则。
说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。
正例：一个类中有多个 public 方法，都需要进行数行相同的参数校验操作，这个时候请抽取：
private boolean checkParam(DTO dto) {...}
32 . 【强制】对 trace / debug / info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式。
说明： logger . debug( " Processing trade with id : " + id + " and symbol : " + symbol);
如果日志级别是 warn ，上述日志不会打印，但是会执行字符串拼接操作，如果 symbol 是对象，会执行 toString()方法，浪费了系统资源，执行了上述操作，最终日志却没有打印。
正例： （ 条件 ）
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
}
正例： （ 占位符 ）(推荐所有带参数的日志均用此种方式)
logger.debug("Processing trade with id: {} and symbol : {} ", id, symbol);
33 . 【强制】避免重复打印日志，浪费磁盘空间，务必在 log 4 j . xml 中设置 additivity = false 。
正例： <logger name="com.taobao.dubbo.config" additivity="false">
34 . 【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出。
正例： logger.error(各类参数或者对象 toString + "_" + e.getMessage(), e);
35 . 【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志 ； 有选择地输出 info 日志 ； 如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。 说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？
36 . 【参考】可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。注意日志输出的级别， error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必要，请不要在此场景打出 error 级别。
========================= MySql数据库 ========================
1 . 1. 【强制】表达是与否概念的字段，必须使用 is _ xxx 的方式命名，数据类型是 unsigned tinyint（ 1 表示是，0 表示否 ） 。
说明：任何字段如果为非负数，必须是 unsigned 。
正例：表达逻辑删除的字段名 is_deleted ，1 表示删除，0 表示未删除。
2 . 【强制】表名、字段名必须使用小写字母或数字 ， 禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。
正例： aliyun _ admin ， rdc _ config ， level 3_ name
反例： AliyunAdmin ， rdcConfig ， level _3_ name
3 . 【强制】禁用保留字，如 desc 、 range 、 match 、 delayed 等，请参考 MySQL 官方保留字
4 . 【强制】 varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text ，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
5 . 【推荐】单表行数超过 500 万行或者单表容量超过 2 GB ，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
6 . 【强制】不要使用 count( 列名 ) 或 count( 常量 ) 来替代 count( * ) ， count( * ) 是 SQL 92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。
说明： count( * ) 会统计值为 NULL 的行，而 count( 列名 ) 不会统计此列为 NULL 值的行。
7 . 【强制】当某一列的值全是 NULL 时， count(col) 的返回结果为 0，但 sum(col) 的返回结果为NULL ，因此使用 sum() 时需注意 NPE 问题。
正例：可以使用如下方式来避免 sum 的 NPE 问题： SELECT IF(ISNULL(SUM(g)) ,0, SUM(g))FROM table;
8 . 【强制】使用 ISNULL() 来判断是否为 NULL 值。
说明： NULL 与任何值的直接比较都为 NULL。
1 ） NULL<>NULL 的返回结果是 NULL ，而不是 false 。
2 ） NULL=NULL 的返回结果是 NULL ，而不是 true 。
3 ） NULL<>1 的返回结果是 NULL ，而不是 true 。
9 . 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
说明：以学生和成绩的关系为例，学生表中的 student _ id 是主键，那么成绩表中的 student _ id则为外键。如果更新学生表中的 student _ id ，同时触发成绩表中的 student _ id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群 ；
级联更新是强阻塞，存在数据库更新风暴的风险 ； 外键影响数据库的插入速度。
10 . 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
11 . 【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。
说明： resultClass=”Hashtable” ，会置入字段名和属性值，但是值的类型不可控。
12 . 【推荐】不要写一个大而全的数据更新接口。传入为 POJO 类，不管是不是自己的目标更新字段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL时，不要更新无改动的字段，一是易出错 ； 二是效率低 ； 三是增加 binlog 存储。
13 . 【参考】@ Transactional 事务不要滥用。事务会影响数据库的 QPS ，另外使用事务的地方需
要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
扫一扫
621
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
