一、命名
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、建立完善的 代码审查机制,以便及时发现和修复“破窗”