一、命名

1、有意义的命名

如果你无法想出一个合适的名字，很可能意味着代码“坏味道”、设计有问题。这时可以思考一下：是不是方法里实现了太多的功能？或者类的封装内聚性不够？

2、函数名

函数命名要具体，空泛的命名没有意义。函数的命名要体现做什么，功能是什么，而不是怎么实现。

3、类名

可以将类分为两大类：实体类和辅助类

辅助类是辅佐实体类一起完成业务逻辑的，其命名要能通过后缀来体现功能。

例如：用来为Customer做控制路由的类为CustomerController,提供服务的类 CustomerService、提供数据持久化的类CustomerRepository

4、命名一致性

1）方法名前缀约定

新增   create
添加   add
删除   remove
修改   update
查询（单个结果） get
查询（多个结果） list
分页查询     page
统计    count

2）使用对仗词

add--》remove
increment--》decrement
open--》close
begin--》end
insert--》delete
show--》hide
create--》destory
lock--》unlock
source--》target
first--》last
min--》max
start--》stop
get--》set
next--》previous
up--》down
old--》new

3）后置限定词

把限定词 Total、Sum、Average、Max、Min加到名字的最后，保持一致的风格，就会比较优雅。例如：revenueTotal 总收入 、expenseTotal 总支出、revenueAverage平均收入、expenseAverage 平均支出

4）统一技术语言

VO、DTO、DO、DAO、PO、ServiceI、ServiceImpl、Component、Repository

5）命名参考

当你不知道如何优雅的命名时，可以模拟开源项目框架中是如何命名的，哪些使用频率高，看看大神都是怎么命名的。

二、规范

1、常量命名的字母全部大写，单词之间用下划线连接

TOTAL_COUNT、PAGE_SIZE

2、枚举类以Enum或者Type结尾

SexEnum.MALE、SexEnum.FEMALE

3、抽象类名使用 Abstract开头；异常类使用 Exception结尾；实现类以Impl结尾；测试类以Test结尾

4、包名统一小写，点分隔符之间有且仅有一个自然语义的英文单词，包名统一使用单数形式

5、异常处理

业务系统中设定两个异常：BizException 代表业务异常， SysException代表系统异常，而且这两个异常都是 Unchecked Exception。

C#、Python、Ruby语言都不支持 Checked Exception，因为其依赖成本要高于显示声明带来的收益。

最后针对业务异常和系统异常要做统一的异常处理，在应用处理请求的切面上进行异常处理收敛，其处理流程如下：

try{Response res = proces(request);
}`catch(BizException e){//业务异常使用 warn级别logger.warn("bizexception error code{},error message{}",e.getErrorCode(),e.getErrorMsg());
} catch(SysException ex){//系统异常使用ERROR级别logger.error("system error"+ex.getMessage(),ex);} catch(Exception ex){//兜底logger.error("error:"+ex.getMessage().ex);
}

千万不要在业务处理内部到处使用try catch 打印错误日志，这样会使功能代码和业务代码缠绕在一起，让代码显得很凌乱，而且影响代码的可读性。

6、显性化错误码

可以这样约定：

P 代码参数异常（ParamException）、B代码业务异常（BizException）、S代码系统异常（SystemException）

参数异常的错误码约定: P_XX_XX 例如：B_Customer_NameIsNull  客户姓名不能为空

业务异常的错误码约定: B_XX_XX  例如:B_Customer_NameAlreadyExist客户姓名已存在

系统异常的错误码约定:  S_XX_XX  ,例如:S_Unknow_Error  未知系统错误

7、建立完善的 代码审查机制，以便及时发现和修复“破窗”