Java开发规范之常量定义篇
Java开发规范之常量定义篇
开发团队在开发过程中,由于每个人的开发习惯,以及对于技术的理解深浅程度不一,往往一个项目在开发过程中,代码的质量,代码的风格都不尽相似,所以有一份适合团队的代码规范是非常有必要的,而一个团队的代码规范,包含了开发常见的风格习惯以及一些常见代码细节的写法规范等。
本系列文章将整合 阿里巴巴《Java开发手册》和 谷歌《Java编程规范》,总结Java开发过程的编码规范,并通过具体编码案例给出编码规范的原因,如果总结内容存在问题还望指出。
目录
1.禁止魔法值
2.长整性类型赋值数值后使用大写L
3.常量需要根据功能放置在不同常量类
4.常量的复用层次
5.固定范围的变量使用enum类型
之前的文章已经介绍过命名规范(点击 Java开发规范之命名篇(上)和 Java开发规范之命名篇(下)访问),本文将进一步介绍常量定义规范,虽然之前的文章有提到常量规范但也只是限于命名,本篇将讨论常量定义和使用过程的具体细则,包括定义格式,如何归类和复用范围等。
1.禁止魔法值
【Alibaba】不允许任何魔法值(即未经预先定义的常量)直接出现在代码中。
【Google】未明确定义类似规范
说明:魔法值是指带代码中直接使用的数值或者字符串,只有在这个数值记述的那部分代码中才能明确了解其含义,比如拼接字符串前缀。
反例:
补充:反例1和2出现了魔法值 “1” 和 “stop”,可以使用static final 定义常量或使用enum值
2.长整性类型赋值数值后使用大写L
【Alibaba】在long或者Long赋值时,数值后使用大写的L,不能是小写的l,小写容易跟数字1混淆,造成误解。
【Google】未明确定义类似规范
说明:小写的l无法区分写的是数字的1,还是Long型标识。
反例:
3.常量需要根据功能放置在不同常量类
【Alibaba】不要使用一个常量类维护所有常量,要按常量功能进行归类,分开维护。
【Google】未明确定义类似规范
说明:大而全的常量类,杂乱无章,使用查找功能才能定位到修改的常量,不利于理解和维护。
正例:【Alibaba】缓存相关常量放在类CacheConsts下;系统配置相关常量放在类ConfigConsts下。
反例:【Alibaba】日期格式常量和字符串常量放置在同一个常量类中。
4.常量的复用层次
【Alibaba】常量的复用层次有五层:跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
- 1) 跨应用共享常量:放置在二方库中,通常是client.jar中的constant目录下。
- 2) 应用内共享常量:放置在一方库中,通常是子模块中的constant目录下。
- 3) 子工程内部共享常量:即在当前子工程的constant目录下。
- 4) 包内共享常量:即在当前包下单独的constant目录下。
- 5) 类内共享常量:直接在类内部private static final定义。
【Google】未明确定义类似规范
反例:【Alibaba】针对上述条例 2,易懂变量也要统一定义成应用内共享常量,两位工程师在两个类中分别定义了“YES”的变量: 类A中:public static final String YES = "yes"; 类B中:public static final String YES = "y"; A.YES.equals(B.YES),预期是true,但实际返回为false,导致线上问题。
5.固定范围的变量使用enum类型
【Alibaba】如果变量值仅在一个固定范围内变化用enum类型来定义。
【Google】未明确定义类似规范
说明:如果存在名称之外的延伸属性应使用enum类型。
正例: