良好的代码习惯：

    • 保持一个风格的代码格式
    • 合理使用空行：
      • 空行是为了便于阅读，一般而言，每行后面都加空行等于都没加空行，都不利于阅读
      • 一般使用规则：联系紧密的内容之间不要用空行隔开，将不联系不紧密的内容用空行隔开
    • java 命名规范：
      • 类名：大驼峰形式，即首字母大写的驼峰，如Object、StringBuffer
      • 方法名：小驼峰形式，即第一个单词首字母小写，其余单词首字母大写，如 readObject() 等
      • 常量：全大写，各个单词之间使用下划线隔开，如 TOTAL_PAGE、UPDATE_ERROR 等
      • 枚举类：枚举类命名以 Enum 或 Type 结尾
      • 枚举类成员：全大写，各个单词之间使用下划线隔开，如 TOTAL_PAGE、UPDATE_ERROR 等
      • 特殊类：
        • 抽象类：以 Abstract 开头
        • 异常类：以 Exception 结尾
        • 实现类：以 Impl 结尾
        • 测试类：以要测试的类名开始，以 Test 结尾
      • 包名：同一使用小写，点分隔符之间有且只有一个自然语义的单词，包名统一使用单数形式，通常为 com 或 org 开头，加上公司名，然后再加上组件或者功能模块名
    • 日志规范：关注四个级别的日志
      • ERROR：表示不能自己恢复的错误，需要立即被关注和解决
      • WARN：对于可预知的业务问题，最好不用使用 ERROR 输出日志，避免污染报警系统；同样，也需要设置一个 WARN 阈值，方便通知处理
      • INFO：记录系统基本的运行过程和运行状态
      • DEBUG：输出调试信息，用于开发环境
    • 异常规范

    异常规范详解：
    1、异常处理：一般在业务系统中设置两个异常，且都设置为 Unchecked Exception

    • BizException：业务异常
    • SysException：系统异常

    为什么不设置为 Checked Exception 呢？
    因为破坏了开闭原则，如果在一个方法中抛出了 Checked Exception，而 catch 语句在 3 个层级之上，那么就需要在 catch 语句和抛出异常之间的每个方法签名中声明该异常，这意味着在软件中修改较 低层级时，都将波及较高层级，修改好的模块必须重新构建、发布，即便它们自身所关注的任何东西都没有被改动过。

    针对业务异常的处理：类似AOP，在应用处理请求的切面上进行异常处理收敛

    2、错误码

    • 对错误码进行编号
    • 显性化错误码：
      • 即将错误码命名定义成3个部分：类型 + 场景 + 自定义标识
      • 错误类型约定：
        • P：ParamException，参数异常
        • B：BizException，业务异常
        • S：SystemException，系统异常 | 错误类型 | 错误码约定 | 举例 | | —- | —- | —- | | 参数异常 | P_XX_XX | P_Customer_NameIsNull：客户姓名不能为空 | | 业务异常 | B_XX_XX | B_Customer_NameAlreadyExist：客户姓名已经存在 | | 系统异常 | S_XX_XX | S_Unknown_Error：位置系统错误 |