Java开发规范
一. 命名规约
1.【强制】不允许以下划线或$为首字母命名，也不允许以此结尾
2.【强制】变量的命名要有意义
3.【强制】类名与接口名使用UpperCamelCase风格，遵从驼峰形式
4.【强制】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式
5.【强制】常量命名全部大写，单词间用下划线隔开，枚举一样
6.【强制】POJO类（DTO/PO/VO...）中布尔类型的变量，都不要加is前缀，否则部门框架解析会引起序列化错误（如果是底层接口提供的契约除外）
7.【强制】包名全部小写，点分割符之间尽量只有一个英语单词，即使有多个单词也不要使用下划线或大小写分割
8.【强制】不允许魔数的出现，即未经定义出现在代码中的
二.注释规约
1.【强制】类、类的公有成员、方法的注释必须使用Javadoc规范，使用/** xxx*/格式，不得使用//xxx方式
2.【推荐】注释的双斜线与注释内容之间有且仅有一个空格
3.【强制】所有的枚举类型字段必须有注释，说明每个数据项的用途
4.【推荐】代码修改的同时，注释也要进行相应的修改
5【推荐】TODO标记，清晰说明待办事项和处理人
6【推荐】确定后面不用的方法最好删除而不是整个注释掉，如果有其他地方调用需要加上@Deprecated标记已弃用，并注释说明对应的代替方法是什么
三.格式规约
1.【强制】long或者Long赋值时，使用大写的L，不能是小写的l，小写容易跟数字1混淆，造成误解
2.【推荐】枚举类名以Enum结尾，抽象类使用Abstract或者Base开头，异常类使用Exception结尾，测试类以它要测试的类名开始，以Test结尾，如果模块、接口、类、如果是实现类尽量用Impl的后缀与接口关联
3.【推荐】不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护
4.【推荐】通过空行进行逻辑分段，不同业务逻辑的代码行之间，插入一个空行，起逻辑分段的作用
5.【推荐】保持代码格式化风格的统一，建议使用公司统一的代码格式化配置
6.【强制】三目运算符的左右两边都需要加一个空格
7.【推荐】一行代码的字符数最好不超过120个（即Idea里的那条竖线），超出需要换行
8.【强制】方法参数在定义和传入时，多个参数逗号后边必须加空格
9.【强制】所有的覆写方法，必须加@ovveride注解，虽然不加也不会报错，但是如果父类改了方法名，则子类原来重写的方法默认变成了一个新方法而不是父类，编译器也无法检测出来
10.【强制】所有的相同类型的包装类对象之间值的比较，全部使用equals方法比较
11.【强制】使用常量或确定有值的对象来调用equals，否则可能会导致空指针异常
12.原子数据类型（int等）与包装类型（Integer等）的使用原则
1>【强制】所有的POJO类属性必须使用包装数据类型
2>【推荐】RPC方法的返回值和参数必须使用包装数据类型
3>【推荐】所有的局部变量使用基本数据类型
13.【推荐】类内方法定义顺序依次是：公有方法或保护方法>私有方法>getter/setter方法
14.【推荐】循环体内的字符串连接方式，使用StringBuilder（无锁）的append方法进行扩展
15.【推荐】自动转换(AutoBoxing)有一定成本，调用者与被调用函数间尽量使用同一类型，减少默认转换
16.【强制】数字运算表达式，因为先进行等式右边的运算，再赋值给等式左边的变量，所以等式两边的类型要一致
17.【推荐】字符操作时，优先使用字符参数，而不是字符串，能提升性能，因为类型向上转型
18.【推荐】利用好正则表达式的预编译功能，可以有效加快正则匹配速度
四. 常用api使用规则
1.【强制】禁止使用new BigDecimal(double val)方法初始化，做除法运算时需要设置小数精度，比较大小时使用compareTo方法
2.【强制】比较Enum枚举的值是否相等时需要确保两边的类型一致
3.【强制】switch()接收的参数不支持null，传入会抛错，这点和C#不同，使用前必须确保不会为null
4.【强制】使用Array.asList()将数组转成集合后禁止调用add和remove()方法
5.【推荐】尽量不要使用枚举值默认的ordinal属性做判断，如果新增的枚举值不是写在最后会导致其后面的枚举值
6.【推荐】使用MessageFormat代替String.format替换占位符操作
7.【推荐】在多语言环境下做字符串比较时，如果要忽略两边大小写不一致的情况，使用String.equalsIgnoreCase()方法，不要使用toLowerCase().equals的形式
8.【参考】针对大量字符串截取操作时尽量使用StringTokenizer
五.方法规约
1.【推荐】方法内的行数不要超过100行(sonar)会扫处理
2.【推荐】超过5行以上重复的代码，可以考虑抽取公用的方法
3.【推荐】方法参数最好不要超过3个
1>如果多个参数同属于一个对象，直接传递对象
2>将多个参数合并为一个新创建的逻辑对象
3>将函数拆分成多个函数，让每个函数所需的参数减少
4.【推荐】如果方法的返回值可以为null，建议使用Optional包装一下，这样调用方也清楚风险
六.控制语句
1.【强制】if,else,for.do,while语句必须使用大括号，即使只有单条语句
2.【推荐】针对多层if嵌套或多个if-else的情况，可以考虑使用卫语句、Optional、抽取为方法、策略模式、状态模式等方式
3.【推荐】布尔表达式中的布尔运算符(&&,||)的个数不超过3个，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，提高可读性
4.【推荐】简单逻辑，使用三元运算符或Optional，减少if-else语句的编写
5.【推荐】减少使用取反的逻辑，不使用取反的逻辑有利于快速理解，因为在很多情况下取反逻辑存在对应的正向逻辑的写法
6.【推荐】表达式中能造成短路概率较大的逻辑尽量放在前面，使后面的判读可以免于执行
7.【强制】在一个switch快内，每个case要么通过break/return等来终止，要么注释说明程序将继续执行到哪一个case为止，都必须包含一个default语句并且放在最后，即使它什么代码也没有
8.【推荐】避免在循环条件中使用复杂表达式
9.【推荐】循环内不要不断创建对象引用
10.【推荐】尽量采用懒加载的策略，即在需要的时候才创建
11.【推荐】基于效率和类型检查的考虑，应该尽可能使用数组[]，无法确定数组大小和数据类型时才使用ArrayList
七.集合处理
1.【强制】Map中如果key存储的是自定义对象，则必须重写hashCode和equals方法，保证key的唯一性
2.【强制】不要在foreach循环里进行元素的remove操作，remove元素使用Iterator迭代器
3.【推荐】使用entrySet遍历Map类集合KV，而不是keySet方式进行遍历
4.【推荐】利用Set元素唯一的特征，可以快速对一个集合进行去重操作，避免使用List的contains方法进行遍历，对比去重操作
5.【推荐】在能够预估Map存储元素个数的情况下（超过12个键值对）时尽量指定集合初始大小
6.【强制】高度注意各种Map类集合Key/Value能不能储存null值的情况
7.【强制】集合如果存在并发修改的场景，需要使用线程安全的版本
八.并发处理
1.【推荐】使用线程池时尽量保证创建入口的统一和复用，如果大家都去创建自己的线程池来使用，导致线线程池一大堆，而线程池本身也是线程
2.【推荐】全局的非线程安全的对象可考虑使用ThreadLocal存放
3.【推荐】锁的优化原则
4.【推荐】多线程并行处理定时任务时，Timer运行多个TimeTask时，只要其中之一没有捕获抛出的异常，其他任务便会自动终止运行，使用ScheduledExecutorService则没有这个问题
九.异常处理
1.【推荐】自定义异常，建议继承RuntimeException，而不是继承Exception
2.【推荐】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低
3.【强制】捕获异常一定要处理
4.【强制】不能在finally块中使用returun，finally块中的return将代替try块中的return及throw Exception
5.【推荐】在代码中使用“抛异常”还是“返回错误码”的原则
十.单元测试
1.【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下
2.【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别，不要取跨类或跨module项目的测试，只有测试粒度小才能在出错时尽快定位到出错位置，单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的范畴
3.【推荐】单元测试工具建议使用PowerMock，可以对静态方法、构造方法、私有方法以及Final方法进行mock
4.【推荐】单元测试的基本目标：语句覆盖率达到20%（后期稳定后会逐步提高该指标）
5.【推荐】编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量
B：Border，边界值测试，包括循环边界、特出取值、特殊时间点、数据顺序等
C：Correct，正确的输入，并得到预期的结果
D：Design，与设计文档相结合，来编写单元测试
E：Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得到预期的结果，参数校验
6.【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例
7.【推荐】单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项目提测前完成单元测试
8.【推荐】单元测试要经常维护，修改原有代码逻辑的也要相应的同步单元测试代码，新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正，避免单元测试被废弃
十一.其他
1.【强制】数据库表名，字段名必须使用小写字母或数字，禁止出现数字开头
2.【强制】契约contract和client层要保存一致，修改后要及时同步
3.【强制】契约contract的字段要添加完善的注释，方便调用方使用，敏感字段需要使用GDPR加密
4.【强制】提交代码前需要执行mvn compile，确保编译通过，并且符合公司规范检查
5.【强制】二方包版本号统一放在maven项目的pom里管理维护，其他子pom不要再定义版本号
6.【推荐】依赖的二方jar包最好时release版本的，如果对方暂时无法提供也要确保在合并到release分支前提供出来
7.【推荐】项目中使用到的spring注解@Autowired和@Inject格式最好保持统一，建议使用构造函数的方式注入
9.【参考】多利用IDEA的黄色背景提醒，现代的编译器对java新语法的支持和潜在的bug提醒都做的很智能，建议多关注采纳
10.【强制】循环中调用底层接口一定要谨慎
11.【推荐】不建议在HttpContext上下文中存放大量业务数据，以及一些有状态的数据
12.【参考】内部资料
