浅谈Java中的命名规范

现代软件架构的复杂性需要协同开发完成，如何高效地协同呢？

答案是：制定一整套统一的规范。

无规矩不成方圆，无规范难以协同，比如，制订交通法规表面上是要限制行车权，实际上是保障公众的人身安全，试想如果没有限速，没有红绿灯，谁还敢上路行驶？

本文将从java代码的命名规范这一维度，来探讨一下，如何写出健壮的、可读性强的代码，提高项目的可维护性。最重要的是提高我们的编程幸福感。

1.包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。

正例：应用工具包名为com.java.util、类名为stringutils

2.类名、接口名使用uppercamelcase风格，必须遵从驼峰形式，但以下情形例外：do/bo/dto/vo/ao/po/uid等。

正例：userlogincheckservice/userdo

反例：userlogincheckservice/userdo

3.方法名、参数名、成员变量、局部变量都统一使用lowercamelcase风格，必须遵从驼峰形式。

正例：userserviceimpl

反例：userserviceimpl

4.常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

正例：max_book_count/cache_expired_time

反例：max_count/expired_time

5.为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意，即要做到“见名知意”。

正例：在 jdk 中，表达原子更新的类名为：atomicreferencefieldupdater

反例：string a = "李四"; // 天啦噜，鬼知道你这个a是啥意思啊

6.定义数组时，类型与中括号紧挨相连

正例：

int[] array = new int[10];

int array[] = new int[10]; // 不建议这样写

7.抽象类命名使用 abstract 或 base 开头；异常类命名使用 exception 结尾；测试类命名以它要测试的类的名称开始，以 test 结尾。

正例：abstractservice/commonexception/demotest

8.杜绝完全不规范的缩写，避免望文不知义。

反例：abstractclass“缩写”命名成 absclass；condition“缩写” 命名成 condi，此类随意缩写严重降低了代码的可阅读性。

9.如果模块、 接口、类、方法使用了设计模式，在命名时需体现出具体模式

说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。

正例：public class orderfactory;
public class loginproxy;
public class resourceobserver;

10.对于 service 和 dao 类，基于 soa 的理念，暴露出来的服务一定是接口，内部的实现类用impl 的后缀与接口区别。

正例：cacheserviceimpl实现cacheservice接口

11.如果是形容能力的接口名称，取对应的形容词为接口名（通常是–able 的形容词）。

正例：jdk中的comparable接口

12.在long或者long赋值时，数值后使用大写的 l，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。

说明：long a = 2l；写的是数字的 21，还是 long 型的 2 ？？

13.不允许任何魔法值（即未经预先定义的常量）直接出现在代码中

正例：

public static final order_redis_key_prefix = "orderid_";
string orderrediskey = order_redis_key_prefix + orderid;

反例：

string rediskey = "orderid_" + orderid;

14.枚举类名带上enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。

正例：枚举名字为processstatusenum的成员名称：success / unknown_reason