Java规范

强制

• 代码中的命名不能使用$ _刀了或下划线开始和结束
• 命名不能使用拼音汉字，除国际通用名外，如Beijing 此类视同英文
• 类名，使用驼峰命名，如XmlDemo，HtmlTest，TcpClient
• 类名，抽象类以Abstract或Base开头，测试类异常类以Test和Exception结尾
• 属性命名（成员变量，类变量) boolean类型不得以is开头，防止和框架冲突
• 常量，全部大写，单词以下划线分割，要表达见名识意，不要嫌长
• 包名，全部小写，每层有且只能有一个单词，使用单数，如util 而不是utils
  类名可以为复数如，StringUtils
• 尽量避免使用名称相同的变量，以及子父类成员变量，使可读性降低
• 不要自创缩写，使可读性降低，如AbstractHandle->AbsHan，
  公认的缩写是可以使用的
• 判断集合使用isEmpty方法，不要使用size == 0
• Arrays.asList方法是转换List接口的适配器，封装的还是原数组，所以数组和List的写操作，都会互相收到影响，应当谨慎。
• 在循环中如需对集合进行增删操作请使用迭代器，并发场景需对迭代器加锁
• 集合在初始化时，如预先知道大小范围，因指定集合大小，避免resize浪费不必要的资源。
• 注意常用的Map，键值为null允许的情况
  • Hashtable, ConcurrentHashMap 都不允许为null
  • HashMap 都可以为null
  • TreeMap key不可以，value可以为null

• 集合的order和sort
  • ArrayList: order unsort
  • HashMap: unorder unsort
  • TreeSet: order sort

  如果排序了的（sort，实现为比大小）
  就一定是有序的（order，实现为数组或链表）

• 对多资源加锁需保证加锁顺序，否则容易出现死锁
• 三元运算符时两边值为包装类和基本类型时注意表达式的类型被拆包可能的NPE
• 在高并发场景的边界判断中，尽量不要使用等于来判断，应该使用<=0，等程序健壮性更好。
• 方法行数较多时，return 等 结束方法的语句后面加一行空行，清晰易读
• 代码被注释掉情况
  • 1）后续会恢复此段代码逻辑，这种情况需要备注详细说明情况，使用///注释
  • 2）永久不用，建议直接删掉即可，假如需要查阅历史代码，登录代码仓库即可
• RunTimeException能通过判断处理就不要用catch块处理，如if(o == null) dosth 而不是 catch（NullPointException）
• 不要利用异常来做流程控制
• catch稳定代码 可以直接一块捕获，不稳定代码按异常切块分别处理
• 异常捕获了就要处理，异常日志应当包含案发现场信息和异常堆栈信息，例：案发现场信息和异常堆栈信息，如果不进行处理，请抛给调用者
• 不要在finally块中执行return语句，因为try块中的return点会被覆盖，会执行，但不会return，真正return的是finally中的值
• 调用RPC、二方包或动态生成类的方法时，捕获异常使用Throwable，因为运行期可能出现NoSuchMethodError等
• 方法的返回值可以为null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回null值
• 注意return包装类型，而返回类型为基本类型时，可能发生自动拆箱NPE
• 级联调用obj.getA().getB().getC()；一连串调用，易产生NPE，可使用Optional来防止
• 避免直接new Exception 或new RuntimeException，因该使用业务自定义异常
• 避免出现重复的代码（Don'tRepeatYourself），即DRY原则，必要时抽取共性方法，或者抽象公共类，甚至是组件化
• 不可直接使用日志系统中的API，应当使用门面模式的日志框架如，slf4j，jcl
• 日志至少需要保留15天，历史日志加时间后缀，如server.log.2021-08-06
  扩展日志（如打点、临时监控、访问日志等）命名方式appName_logType_logName.log
• 对于trace/debug/info级别的日志输出，必须进行日志级别的开关判断
• 禁止重复打印日志, 设置additivity=false
• 禁止使用system out err, e.printStackTrace()
• 避免打印错误日志调用json对象tostring，可能会有异常导致日志无法打印，应当打印业务相关的属性或调用对象的tostring
• 生产环境日志禁止debug，有选择info，刚上线注意warn，及时删除观察日志

推荐

• 变量命名最后的单词尽量为名词，修饰词放在前边，以提升辨识度
  如redColor 而不是 colorRed
• 使用设计模式时，尽量以模式名称结尾，如，工厂模式xxxFactory代理模式xxxProxy
• 接口定义无需加入public abstract 修饰符，这样代码更简洁
• 接口通常以able形容词结尾，对应的实现类为名词tor等结尾
• 接口通常以Server等其他名词结尾，对应的实现类以Impl结尾
• 枚举类以Enum结尾，成员命名同常量（全大写，下划线分割单词）
• 一行代码太长需要换行时，参数逗号后换行，方法调用点号或运算符在符号前换行
• 错误码为5为，第一位表示错误来源，或者ABC字母如1表示用户错误，2表示服务器错误，3表示第三方调用错误，00000表示成功。

测试

• 好的单元测试必须遵守AIR原则，
  • Automatic（自动化）
  • Independent（独立性）
  • Repeatable（可重复）

单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用System.out来进行人肉验证，必须使用assert来验证
保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序
对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别，不用不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域
单元测试代码必须写在如下工程目录：src/test/java，源码编译时会跳过此目录，而单元测试框架默认是扫描此目录
单元测试的基本目标：语句覆盖率达到70%；核心模块的语句覆盖率和分支覆盖率都要达到100%
编写单元测试代码遵守BCDE原则

- Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
- Correct，正确的输入，并得到预期的结果。
- Design，与设计文档相结合，来编写单元测试。
- Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果

idea 设置 code style

• editor-code style-java-sapces-other-after type cast取消勾选