最近由于工作转型，技术栈也从C++向Java转变，在此总结一下这一个月里在学习Java过程中比较流行的编程风格以及一些风格的使用可能避过的一些坑。

1 命名风格

• 方法名与变量名需使用首字母小写的驼峰命名方法，如localValue、getMethod等
• 常量需要全部大写且以下划线隔开不同的词义，如MAX_NUM
• 抽象类命名以Abstract或Base开头，异常类命名使用Exception结尾，测试类以其测试的类名开头以Test结尾，如AbstractOutput、OutputException、OutputTest
• 类型与中括号紧挨相连来表示数组，如int[] arrayExample
• POJO类中布尔变量不要加is前缀，避免部分框架引起序列化错误
  -包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词
  -避免子父类成员变量以及不同代码块的局部变量使用相同的变量名，这样容易在代码解读过程中造成混淆
  -不要任何魔法值直接出现在代码中，尽量先使用常量定义该魔法值，这样不易造成魔法值书写错误
  -在给long或Long类型复制时，数值后使用大写L而非小写l，避免与数字1混淆

2 代码格式

• 如果是大括号内为空，则简洁地写成{}即可，大括号中间无需换行和空格；如果是非空代码块则： 1） 左大括号前不换行。 2） 左大括号后换行。 3） 右大括号前换行。 4） 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行
• 左小括号和字符之间不出现空格；同样，右小括号和字符之间也不出现空格；而左 大括号前需要空格。反例：if (空格 a == b 空格)
• if/for/while/switch/do 等保留字与括号之间都必须加空格
• 任何二目、三目运算符的左右两边都需要加一个空格
• 采用 4 个空格缩进，禁止使用 tab 字符
• 注释的双斜线与注释内容之间有且仅有一个空格
• 在进行类型强制转换时，右括号与强制转换值之间不需要任何空格隔开。int second = (int)first + 2
• 单行字符数限制不超过 120 个，超出需要换行，换行时遵循如下原则： 1）第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进 2）运算符与下文一起换行。 3）方法调用的点符号与下文一起换行。 4）方法调用中的多个参数需要换行时，在逗号后进行。 5）在括号前不要换行
• 方法参数在定义和传入时，多个参数逗号后边必须加空格method(args1, args2, args3)
• IDE 的 text file encoding 设置为 UTF-8; IDE 中文件的换行符使用 Unix 格式，不 要使用 Windows 格式

3 OOP规约

• 避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析 成本，直接用类名来访问即可
• 所有的覆写方法，必须加@Override注解
• 相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object
• 外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产 生影响。接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么
• Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals，如"test".equals(test)
• 所有整型包装类对象之间值的比较，全部使用 equals 方法比较
• 浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用 equals 来判断,可以用指定误差的方式判断，或使用Double.compare这种方法，也可以使用BigDecimal
• 为了防止精度损失，禁止使用构造方法 BigDecimal(double)的方式把 double 值转 化为 BigDecimal 对象；使用string或BigDecimal recommend2 = BigDecimal.valueOf(0.1);
• 关于基本数据类型与包装数据类型的使用标准如下： 1） 所有的 POJO 类属性必须使用包装数据类型。 2）RPC 方法的返回值和参数必须使用包装数据类型
• POJO 类必须写 toString方法
• 在类内定义另一个类，如果被定义类不是作为该类的成员变量请在被定义类前加static修饰符，以免延长类对象生命周期
• 字符串关联是如果是两个字符串串联可用+，即A + B；若是多个字符串，尤其是在循环语句中进行串联，可使用StringBuilder.append()方法；若变量与常量字符串串联建议使用format方式
• Connections, streams, files 这些个类对象或继承closeble的类对象需要使用“try_with_resources”方法或在final模块中进行关闭
• String.split方法会忽略分隔符之间为空的部分，需要特别注意
• 数据库连接密码或其他密码请不要直接写在代码中，这样会有安全隐患，最好在配置文件或keystore中进行保管

4 集合处理

• 使用集合转数组的方法，必须使用集合的toArray(T[]array)，传入的是类型完全一
  致、长度为 0 的空数组
  正例:
  说明:使用 toArray 带参方法，数组空间大小的 length:
  1. 等于 0，动态创建与 size 相同的数组，性能最好。
  2. 大于 0 但小于 size，重新创建大小等于 size 的数组，增加 GC 负担。
  3. 等于 size，在高并发情况下，数组创建完成之后，size 正在变大的情况下，负面影响与上相同。
  4. 大于 size，空间浪费，且在 size 处插入 null 值，存在 NPE 隐患。
• 在使用 Collection 接口任何实现类的 addAll()方法时，都要对输入的集合参数进行 NPE 判断
• 使用工具类 Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方 法，它的 add/remove/clear 方法会抛出 UnsupportedOperationException 异常
• 在无泛型限制定义的集合赋值给泛型限制的集合时，在使用集合元素时，需要进行 instanceof 判断，避免抛出 ClassCastException 异常
• 不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator 方式，如果并发操作，需要对 Iterator 对象加锁

5 控制语句

• 在一个 switch 块内，每个 case 要么通过 continue/break/return 等来终止，要么 注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使它什么代码也没有
• 在 if/else/for/while/do 语句中必须使用大括号
• 在高并发场景中，避免使用”等于”判断作为中断或退出的条件
• if else 不要超过三层

6 注释规约

• 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用 // xxx 方式
• 所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能
• 所有的类都必须添加创建者和创建日期
• 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐
• 所有的枚举类型字段必须要有注释，说明每个数据项的用途

7 异常日志

• Java 类库中定义的可以通过预检查方式规避的 RuntimeException 异常不应该通过 catch 的方式来处理，比如：NullPointerException，IndexOutOfBoundsException 等等
• 不要在 finally 块中使用 return, 这样会使try中的return失效
• 捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类
• catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。 对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理
• 应用中不可直接使用日志系统（Log4j、Logback）中的 API，而应依赖使用日志框架 SLF4J 中的 API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一
• 所有日志文件至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。网络 运行状态、安全相关信息、系统监测、管理后台操作、用户敏感操作需要留存相关的网络日 志不少于 6 个月
• 在日志输出时，字符串变量之间的拼接使用占位符的方式
• 对于 trace/debug/info 级别的日志输出，必须进行日志级别的开关判断
• 异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字 throws 往上抛出

8 单元测试

• 好的单元测试必须遵守 AIR 原则，也就是你的单元测试就像空气一样不会对程序造成任何影响
• 单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的， 执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。 单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证
• 保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序
• 单元测试是可以重复执行的，不能受到外界环境的影响
• 对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别
• 核心业务、核心应用、核心模块的增量代码确保单元测试通过
• 单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下