一、编程规约

一、编程规约
（一）命名风格

• 不以下划线（_）或美元符号($)开始和结束
• 不用中文拼音
• 避免歧视或侮辱性词语
• 类名用UpperCamelCase风格，以下情况例外：DO/PO/DTO等
• 方法名、参数名、成员变量、局部变量使用lowerCamelCase风格
• 常量名称全部大写，单词间用下划线分开
• 抽象类命名用Abstract或Base开头；异常类命命名使用Exception结尾
• 类型与中括号紧挨相连来定义数组
• POJO类中的布尔类型变量不要加is前缀
• 包名称同一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义可使用复数形式
• 避免在子父类的成员变量之间、或者不同代码块的局部变量之间采取完全相同的命名，使可理解性降低
• 英文缩写要规范
• 对于Service和DAO类，暴露出来的服务一定时接口，内部的实用类用Impl的后缀与接口区别
• 命名可以使用完成的单词进行表达，达到自解释目标
• 常量和变量命名时，表示类型的名词放在词尾
• 命名时要体现出用到的具体设计模式
• 接口类中的方法和属性不加任何修饰符
• 枚举类名带上Enum，枚举成员名词需要全大写，单词间用下划线隔开
• 各层命名规约：
  • Service / DAO 层方法命名规约：
    • 获取单个对象的方法用 get 做前缀
    • 获取多个对象的方法用 list 做前缀，复数结尾，如：listObjects
    • 获取统计值的方法用 count 做前缀
    • 插入的方法用 save / insert 做前缀
    • 删除的方法用 remove / delete 做前缀
    • 修改的方法用 update 做前缀
  • 领域模型命名规约：
    • 数据对象：xxxDO，xxx 即为数据表名
    • 数据传输对象：xxxDTO，xxx 为业务领域相关的名称
    • 展示对象：xxxVO，xxx 一般为网页名称
    • POJO 是 DO / DTO / BO / VO 的统称，禁止命名成 xxxPOJO
      （二）常量定义
• 代码中不要出现未经预先定义的常量
• long或Long赋值时，数值后使用大写L
• 浮点数类型的数值后缀统一为大写的D或F
• 不要使用一个常量类维护所有常量，要按功能分类
• 常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量
• 如果变量值仅在一个固定范围内变化用 enum 类型来定义
  （三）代码格式
• 大括号内为空，简洁地写成{}
• 左小括号和右边相邻字符之间不需要空格；右小括号和左边相邻字符之间也不需要空格
• if / for / while / switch / do 等保留字与左右括号之间都必须加空格
• 任何二目、三目运算符的左右两边都需要加一个空格
• 采用 4 个空格缩进，禁止使用 Tab 字符
• 注释的双斜线与注释内容之间有且仅有一个空格
• 在进行类型强制转换时，右括号与强制转换值之间不需要任何空格隔开
• 单行字符数限制不超过 120 个，超出需要换行，换行时遵循如下原则：
  • 第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进
  • 运算符与下文一起换行
  • 方法调用的点符号与下文一起换行
  • 方法调用中的多个参数需要换行时，在逗号后进行
• 方法参数在定义和传入时，多个参数逗号后面必须加空格
• IDE 的 text file encoding 设置为 UTF-8；IDE 中文件的换行符使用 Unix 格式，不要使用Windows 格式
• 单个方法总行数不超过80行
• 无需对齐两行中的赋值等号
• 不同逻辑、语义、业务的代码之间插入一个空行
  （四）OOP规约
• 使用类名访问静态变量和静态方法
• 复写方法需要加@Override注解
• 相同参数类型，相同业务含义才可以使用可变参数，参数类型避免定义为Object
• 外部正在调用的接口或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响
• 不能使用过时的类或方法
• Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals
• 所有整型包装类对象之间值的比较，全部使用 equals 方法比较
• 任何货币金额，均以最小货币单位且为整形类型进行存储
• 浮点数之间等值判断，不能用==或者equals进行判断
• BigDecimal 的等值比较应使用 compareTo 方法
• 定义数据对象DO类时，属性类型要与数据库字段类型相匹配
• 禁止使用构造方法 BigDecimal(double) 的方法把double值转为为 BigDecimal 对象（因为存在精度损失风险），优先推荐入参为String的构造方法
• 所有的POJO类属性必须使用包装数据类型；RPC方法的返回值和参数必须使用包装数据类型
• 定义 DO / PO / DTO / VO 等 POJO 类时，不要设定任何属性默认值
• 序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败
• 构造方法里面禁止加入任何业务逻辑，初始化逻辑放在 init 方法中
• POJO 类必须写 toString 方法
• 禁止在 POJO 类中，同时存在对应属性 xxx 的 isXxx() 和 getXxx() 方法
• 使用索引访问用 String 的 split 方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛 IndexOutOfBoundsException 的风险
• 当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起，便于阅读
• 类内方法定义的顺序依次是：公有方法或保护方法 > 私有方法 > getter / setter 方法
• setter 方法中，参数名称与类成员变量名称一致，this.成员名=参数名。在 getter / setter 方法中，不要增加业务逻辑
• 循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展
• final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字：
  • 不允许被继承的类，如：String 类
  • 不允许修改引用的域对象，如：POJO 类的域变量
  • 不允许被覆写的方法，如：POJO 类的 setter 方法
  • 不允许运行过程中重新赋值的局部变量
  • 避免上下文重复使用一个变量，使用 final 关键字可以强制重新定义一个变量，方便更好地进行重构
• 慎用 Object 的 clone 方法来拷贝对象（因为是浅复制）
• 类成员与方法访问控制从严
  （五）日期时间
• 日期格式化时，传入 pattern 中表示年份统一使用小写的 y（“yyyy-MM-dd HH:mm:ss”）
• 日期格式中的字母含义
  • 表示月份是大写的 M
  • 表示分钟则是小写的 m
  • 24 小时制的是大写的 H
  • 12 小时制的则是小写的 h
• 获取当前毫秒数：System.currentTimeMillis()；而不是 new Date().getTime()
• 不允许在程序任何地方中使用：java.sql.Date、java.sql.Time、java.sql.Timestamp
• 禁止在程序中写死一年为 365 天，避免在公历闰年时出现日期转换错误或程序逻辑错误
• 避免公历闰年 2 月问题
• 使用枚举值来指代月份。如果使用数字，注意 Date，Calendar 等日期相关类的月份 month 取值范围从 0 到 11 之间
  （六）集合处理
• 关于 hashCode 和 equals 的处理，遵循如下规则：
  • 只要覆写 equals，就必须覆写 hashCode
  • 因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的对象必须覆写这两种方法
  • 如果自定义对象作为 Map 的键，那么必须覆写 hashCode 和 equals
• 判断所有集合内部的元素是否为空，使用 isEmpty() 方法，而不是 size() == 0
• 在使用 java.util.stream.Collectors 类的 toMap() 方法转为 Map 集合时，一定要使用参数类型为 BinaryOperator，参数名为 mergeFunction 的方法，否则当出现相同 key 时会抛出IllegalStateException 异常
• 在使用 java.util.stream.Collectors 类的 toMap() 方法转为 Map 集合时，一定要注意当 value为 null 时会抛 NPE 异常
• ArrayList 的 subList 结果不可强转成 ArrayList，否则会抛出 ClassCastException 异常：java.util.RandomAccessSubList cannot be cast to java.util.ArrayList
  • 说明：subList() 返回的是 ArrayList 的内部类 SubList，并不是 ArrayList 本身，而是 ArrayList 的一个视图，对于SubList 的所有操作最终会反映到原列表上
• 使用 Map 的方法 keySet() / values() / entrySet() 返回集合对象时，不可以对其进行添加元素操作，否则会抛出 UnsupportedOperationException 异常
• Collections 类返回的对象，如：emptyList() / singletonList() 等都是 immutable list，不可对其进行添加或者删除元素的操作
• 在 subList 场景中，高度注意对父集合元素的增加或删除，均会导致子列表的遍历、增加、删除产生 ConcurrentModificationException 异常
• 使用集合转数组的方法，必须使用集合的 toArray(T[] array)，传入的是类型完全一致、长度为0 的空数组
• 使用 Collection 接口任何实现类的 addAll() 方法时，要对输入的集合参数进行 NPE 判断
• 使用工具类 Arrays.asList() 把数组转换成集合时，不能使用其修改集合相关的方法，它的 add / remove / clear 方法会抛出 UnsupportedOperationException 异常
• 泛型通配符来接收返回的数据，此写法的泛型集合不能使用 add 方法，而不能使用 get 方法，两者在接口调用赋值的场景中容易出错
• 在无泛型限制定义的集合赋值给泛型限制的集合时，在使用集合元素时，需要进行instanceof 判断，避免抛出 ClassCastException 异常
• 不要在 foreach 循环里进行元素的 remove / add 操作。remove 元素请使用 iterator 方式，如果并发操作，需要对 iterator 对象加锁
• 在 JDK7 版本及以上，Comparator 实现类要满足如下三个条件，不然 Arrays.sort，Collections.sort 会抛 IllegalArgumentException 异常。说明：三个条件如下：
  • x，y 的比较结果和 y，x 的比较结果相反
  • x > y，y > z，则 x > z
  • x = y，则 x，z 比较结果和 y，z 比较结果相同
• 泛型集合使用时，在 JDK7 及以上，使用 diamond 语法或全省略
• 集合初始化时，指定集合初始值大小
• 使用 entrySet 遍历 Map 类集合 KV，而不是 keySet 方式进行遍历
• 高度注意 Map 类集合 K / V 能不能存储 null 值的情况:
  集合类
  Key
  Value
  Super
  说明
  Hashtable
  不为null
  不为null
  Dictionary
  线程安全
  TreeMap
  不为null
  可为null
  AbstractMap
  线程不安全
  ConcurrentHashMap
  不为null
  不为null
  AbstractMap
  锁分段技术（JDK8:CAS）
  HashMap
  可为null
  可为null
  AbstractMap
  线程不安全
• 合理利用好集合的有序性（sort）和稳定性（order），避免集合的无序性（unsort）和不稳定性（unorder）带来的负面影响
• 利用 Set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 List 的contains() 进行遍历去重或者判断包含操作
  （七）并发处理
• 获取单例对象需要保证线程安全，其中的方法也要保证线程安全
• 创建线程或线程池时请指定有意义的线程名称，方便出错时回溯
• 线程资源必须通过线程池提供，不允许在应用中自行显式创建线程
• 线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
• SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为 static，必须加锁，或者使用 DateUtils 工具类
• 必须回收自定义的 ThreadLocal 变量记录的当前线程的值，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的 ThreadLocal 变量，可能会影响后续业务逻辑和造成内存泄露等问题。+尽量在代码中使用 try-finally 块进行回收
• 高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁
• 对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁
• 在使用阻塞等待获取锁的方式中，必须在 try 代码块之外，并且在加锁方法与 try 代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在 finally 中无法解锁
• 在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是否持有锁。锁的释放规则与锁的阻塞等待方式相同
• 并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用 version 作为更新依据
• 多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题
• 资金相关的金融敏感信息，使用悲观锁策略
• 使用 CountDownLatch 进行异步转同步操作，每个线程退出前必须调用 countDown 方法，线程执行代码注意 catch 异常，确保 countDown 方法被执行到，避免主线程无法执行至 await 方法，直到超时才返回结果
• 避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一 seed 导致的性能下降
• 通过双重检查锁（double-checked locking），实现延迟初始化需要将目标属性声明为volatile 型
• volatile 解决多线程内存不可见问题对于一写多读，是可以解决变量同步问题，但是如果多写，同样无法解决线程安全问题
• HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在开发过程中注意规避此风险
• ThreadLocal 对象使用 static 修饰，ThreadLocal 无法解决共享对象的更新问题
  （八）控制语句
• 在一个 switch 块内，每个 case 要么通过 continue / break / return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使它什么代码也没有
• 当 switch 括号内的变量类型为 String 并且此变量为外部参数时，必须先进行 null 判断
• 在 if / else / for / while / do 语句中必须使用大括号
• 三目运算符 condition ? 表达式 1：表达式 2 中，高度注意表达式 1 和 2 在类型对齐时，可能抛出因自动拆箱导致的 NPE 异常
• 在高并发场景中，避免使用“等于”判断作为中断或退出的条件
• 当方法的代码总行数超过 10 行时，return / throw 等中断逻辑的右大括号后需要加一个空行
• 表达异常的分支时，少用 if-else 方式
• 除常用方法（如 getXxx / isXxx）等外不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性
• 不要在其它表达式（尤其是条件表达式）中，插入赋值语句
• 循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的 try-catch 操作（这个 try-catch 是否可以移至循环体外）
• 避免采用取反逻辑运算符
• 公开接口需要进行入参保护，尤其是批量操作的接口
  （九）注释规范
• 类、类属性、类方法的注释必须使用 Javadoc 规范，使用 /** 内容 */ 格式，不得使用 // xxx方式
• 所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数异常说明外，还必须指出该方法做什么事情，实现什么功能
• 所有的类都必须添加创建者和创建日期
• 方法内部单行注释，在被注释语句上方另起一行，使用 // 注释。方法内部多行注释使用 /* */注释，注意与代码对齐
• 所有的枚举类型字段必须要有注释，说明每个数据项的用途
• 可用中文注释说清楚，专有名词与关键字保持英文原文即可
• 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等
• 在类中删除未使用的任何字段和方法、内部类；在方法中删除未使用的参数声明与内部变量
• 谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除
• 对于注释的要求：第一、能够准确反映设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息
• 好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的另一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释又是相当大的负担
• 免出现注释的另一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释又是相当大的负担
• 特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描，经常清理此类标记
  （十）前后端规约
• 前后端交互的 API，需要明确协议、域名、路径、请求方法、请求内容、状态码、响应体
  • 协议：生产环境必须使用 HTTPS
  • 路径：每一个 API 需对应一个路径，表示 API 具体的请求地址：
    • 代表一种资源，只能为名词，推荐使用复数，不能为动词，请求方法已经表达动作意义
    • URL 路径不能使用大写，单词如果需要分隔，统一使用下划线
    • 路径禁止携带表示请求内容类型的后缀，比如".json"，“.xml”，通过 accept 头表达即可
  • 请求方法：对具体操作的定义，常见的请求方法如下：
    • GET：从服务器取出资源。
    • POST：在服务器新建一个资源。
    • PUT：在服务器更新资源。
    • DELETE：从服务器删除资源。
  • 请求内容：URL 带的参数必须无敏感信息或符合安全要求；body 里带参数时必须设置 Content-Type。
  • 响应体：响应体 body 可放置多种数据类型，由 Content-Type 头来确定
• 前后端数据列表相关的接口返回，如果为空，则返回空数组[]或空集合{}
• 服务端发生错误时，返回给前端的响应信息必须包含 HTTP 状态码，errorCode、errorMessage、用户提示信息四个部分
• 在前后端交互的 JSON 格式数据中，所有的 key 必须为小写字母开始的 lowerCamelCase风格，符合英文表达习惯，且表意完整
• errorMessage 是前后端错误追踪机制的体现，可以在前端输出到 type=“hidden” 文字类控件中，或者用户端的日志中，帮助我们快速地定位出问题
• 对于需要使用超大整数的场景，服务端一律使用 String 字符串类型返回，禁止使用 Long 类型
• HTTP 请求通过 URL 传递参数时，不能超过 2048 字节
• HTTP 请求通过 body 传递内容时，必须控制长度，超出最大长度后，后端解析会出错
• 在翻页场景中，用户输入参数的小于 1，则前端返回第一页参数给后端；后端发现用户输入的参数大于总页数，直接返回最后一页
• 服务器内部重定向必须使用 forward；外部重定向地址必须使用 URL 统一代理模块生成，否则会因线上采用 HTTPS 协议而导致浏览器提示“不安全”，并且还会带来 URL 维护不一致的问题
• 服务器返回信息必须被标记是否可以缓存，如果缓存，客户端可能会重用之前的请求结果
• 服务端返回的数据，使用 JSON 格式而非 XML
• 前后端的时间格式统一为"yyyy-MM-dd HH:mm:ss"，统一为 GMT
• 在接口路径中不要加入版本号，版本控制在 HTTP 头信息中体现，有利于向前兼容
  （十一）其他
• 在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度
• 避免用 ApacheBeanutils 进行属性的 copy
• velocity 调用 POJO 类的属性时，直接使用属性名取值即可，模板引擎会自动按规范调用 POJO的 getXxx()，如果是 boolean 基本数据类型变量（boolean 命名不需要加 is 前缀），会自动调 isXxx()
• 后台输送给页面的变量必须加 $!{var} ——中间的感叹号
• 注意 Math.random() 这个方法返回是 double 类型，注意取值的范围 0 ≤ x < 1（能够取到零值，注意除零异常），如果想获取整数类型的随机数，不要将 x 放大 10 的若干倍然后取整，直接使用 Random 对象的 nextInt 或者 nextLong 方法
• 枚举 enum（括号内）的属性字段必须是私有且不可变
• 不要在视图模板中加入任何复杂的逻辑运算
• 任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存
• 及时清理不再使用的代码段或配置信息
  添加评论