命名规约 - 知识库

(一) 命名规约 Rule 1. 【强制】禁止拼音缩写，避免阅读者费劲猜测；尽量不用拼音，除非中国式业务词汇没有通用易懂的英文对应。禁止： DZ[打折] / getPFByName() [评分] 尽量避免：Dazhe / DaZhePrice Rule 2. 【强制】禁止使用非标准的英文缩写反例： AbstractClass 缩写成 AbsClass；condition 缩写成 condi。 Rule 3. 【强制】禁用其他编程语言风格的前缀和后缀在其它编程语言中使用的特殊前缀或后缀，如_name, name_, mName, i_name，在Java中都不建议使用。 Rule 4. 【推荐】命名的好坏，在于其“模糊度” 1）如果上下文很清晰，局部变量可以使用 list 这种简略命名，否则应该使用 userList 这种更清晰的命名。 2）禁止 a1, a2, a3 这种带编号的没诚意的命名方式。 3）方法的参数名叫 bookList ，方法里的局部变量名叫 theBookList 也是很没诚意。 4）如果一个应用里同时存在 Account、AccountInfo、AccountData 类，或者一个类里同时有 getAccountInfo()、getAccountData(), save()、 store() 的函数，阅读者将非常困惑。 5） callerId 与 calleeId， mydearfriendswitha 与 mydearfriendswithb 这种拼写极度接近，考验阅读者眼力的。 Rule 5. 【推荐】包名全部小写。点分隔符之间尽量只有一个英语单词，即使有多个单词也不使用下划线或大小写分隔正例： com.vip.javatool 反例： com.vip.java_tool, com.vip.javaTool Sonar-120:Package names should comply with a naming convention Rule 6. 【强制】类名与接口名使用UpperCamelCase风格，遵从驼峰形式 Tcp, Xml等缩写也遵循驼峰形式，可约定例外如：DTO/ VO等。正例：UserId / XmlService / TcpUdpDeal / UserVO 反例：UserID / XMLService / TCPUDPDeal / UserVo Sonar-101:Class names should comply with a naming convention Sonar-114:Interface names should comply with a naming convention Rule 7. 【强制】方法名、参数名、成员变量、局部变量使用lowerCamelCase风格，遵从驼峰形式正例： localValue / getHttpMessage(); Sonar-100:Method names should comply with a naming convention Sonar-116:Field names should comply with a naming convention Sonar-117:Local variable and method parameter names should comply with a naming convention Rule 8. 【强制】常量命名全大写，单词间用下划线隔开。力求语义表达完整清楚，不要嫌名字长正例： MAX_STOCK_COUNT 反例： MAX_COUNT 例外：当一个static final字段不是一个真正常量，比如不是基本类型时，不需要使用大写命名。 private static final Logger logger = Logger.getLogger(MyClass.class); 例外：枚举常量推荐全大写，但如果历史原因未遵循也是允许的，所以我们修改了Sonar的规则。 Sonar-115:Constant names should comply with a naming convention Sonar-308:Static non-final field names should comply with a naming convention Rule 9. 【推荐】如果使用到了通用的设计模式，在类名中体现，有利于阅读者快速理解设计思想正例：OrderFactory， LoginProxy ，ResourceObserver Rule 10. 【推荐】枚举类名以Enum结尾; 抽象类使用Abstract或Base开头；异常类使用Exception结尾；测试类以它要测试的类名开始，以Test结尾正例：DealStatusEnum， AbstractView，BaseView， TimeoutException，UserServiceTest Sonar-2166:Classes named like "Exception" should extend "Exception" or a subclass Sonar-3577:Test classes should comply with a naming convention Rule 11. 【推荐】实现类尽量用Impl的后缀与接口关联，除了形容能力的接口正例：CacheServiceImpl 实现 CacheService接口。正例: Foo 实现 Translatable接口。 Rule 12. 【强制】POJO类中布尔类型的变量名，不要加is前缀，否则部分框架解析会引起序列化错误反例：Boolean isSuccess的成员变量，它的GET方法也是isSuccess()，部分框架在反射解析的时候，“以为”对应的成员变量名称是success，导致出错。 Rule 13. 【强制】避免成员变量，方法参数，局部变量的重名复写，引起混淆类的私有成员变量名，不与父类的成员变量重名方法的参数名/局部变量名，不与类的成员变量重名 (getter/setter例外) 下面错误的地方，Java在编译时很坑人的都是合法的，但给阅读者带来极大的障碍。 public class A { int foo; } public class B extends A { int foo; //WRONG int bar; public void hello(int bar) { //WRONG int foo = 0; //WRONG } public void setBar(int bar) { //OK this.bar = bar; } }