命名规约
- 类名采用大驼峰形式，一般为名词，例如 Object.但以下情形例外：（领域模型的相关命名）DO/ BO / DTO/ VO等。
- 方法名采用小驼峰形式，一般为动词，与参数组成动宾结构，例如wait（）。
- 变量包括参数 成员变量、局部变量等 也采用小驼峰形式。
- 包名统使用小写，点分隔符之间有且仅有1个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义可以使用复数形式。
- 抽象类命名使用 Abstract Base 开头 异常类命名使用 Exception 结尾，测试类命名以它要测试的类名开始，以Test结尾。
- POJO类中布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误，比如属性 isDeleted，get set方法中会出错的
重点注意：
-
注意userId 中的id不能全大写，Udp、Xml、Tcp等等也不能全用大写
-
常量的命名方式比较特殊，字母全部大写，单词之间用下画线连接。力求语义表达完整清楚，不要嫌名字长，比如，把最大库存数量命名为MAX_STOCK_COUNT
-
枚举类名带上Enum后缀，枚举成员名称需要全大写，单词间用下画线隔开（好处是使用 IDEA可以 ShiftShift搜索很快，所有的枚举类都知道了）
-
望文知义是在不需要额外解释的情况下 仅从名称上就能够理解某个词旬的确切含义。命名做到望文知义、自解释是每个开发工程师的基本素质之一。不要为了缩减长度而取不完整的字符，IDEA有自动生成的功能。
-
杜绝完全不规范的缩写，避免望文不知义。反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成condi，此类随意缩写严重降低了代码的可阅读性
-
接口类中的方法和属性不要加任何修饰符号（public也不要加），保持代码的简洁性，并加上有效的Javadoc注释。
尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量 -
接口和实现类的命名：对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。正例：CacheServiceImpl实现CacheService接口。
-
Service/DAO 层方法命名规约
1） 获取单个对象的方法用 get 做前缀。
2） 获取多个对象的方法用 list 做前缀。
3） 获取统计值的方法用 count 做前缀。
4） 插入的方法用 save（推荐）或 insert 做前缀。
5） 删除的方法用 remove（推荐）或 delete 做前缀。
6） 修改的方法用 update 做前缀。
常量定义
-
不允许出现任何魔法值（即未经定义的常量）直接出现在代码中。
反例： String key="Id#taobao_"+tradeId； -
long 或者 Long 初始赋值时，必须使用大写的 L，不能是小写的 l，小写容易跟数字1 混淆，造成误解。
说明：Long a = 2l; 写的是数字的 21，还是 Long 型的 2l -
不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护。如：缓存相关的常量放在类：CacheConsts 下；系统配置相关的常量放在类：ConfigConsts 下。
说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
网友评论