(一):命名规约
*1.代码中的命名均不能以下划线或美元符号开始,也不能以下划线或 美元符号结束
* 反例:_name/$Object/name_/Object$
*
*2.代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式
* 正例:alibaba/taobao/youku/hangzhou等国际通用的名称,可视同英文。
* 反例:DaZhePromotion[打折]/getPingFenByName()[评分] /int 某变量=3
* 3.类名使用UpperCamelCase风格,必须遵从驼峰形式,但以下情形例外:(领域模型的相关命名)DO/BO/DTO/VO等。
* 4.方法名,参数名,成员变量,局部变量都要统一使用小写命名风格,必须遵从驼峰形式。
* 正例:localValue/getHttpMessage()/inputUserId
* 5.常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。
* 正例:MAX_STOCK_COUNT
* 反例:MAX_COUNT
* 6.抽象类命名使用Abstract或Base开头;异常类命名使用Eception结尾,测试类命名以它要测试的类的名称开始。以Test结尾。
* 7.中括号是数组类型的一部分,数组定义如下:String[] args;反例:请勿使用String args[]的方式来定义。
* 8.POJO类中布尔类型的变量,都不要加is,否则部分框架解析会引起序列化错误。
* 反例:定义为基本数据类型boolean isSuccess的属性;
* 它的方法也是isSuccess(),RPC框架在反向解析的时候,"以为"对应的属性名称是success,导致属性获取不到,进而抛出异常。
* 9.包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。
* 正例:应用工具类包名为com.alibaba.open.util。类名为MessageUtils.
* 10.杜绝完全不规范的缩写,避免望文不知义。
* 反例:AbstractClass"缩写"命名为AbsClass,condition"缩写"命名为condi,此类随意缩写严重降低了代码的可阅读性。
*
* 11.如果使用到了设计模式,建议在类名中体现出具体模式。
* 说明:将设计模式体现在名字中,有利于阅读者快速理解架构设计思想。
* 正例:public class OrderFactory;
* public class LoginFactory;
* public class ResourceObserver;
*
* 12.接口类中的方法和属性不要加任何修饰符号(public也不要加),保持代码的简洁性,并加上有效的javadoc注释。
* 尽量不要在接口里定义变量,如果一定要定义变量,肯定是与接口方法相关,并且是整个应用的基础常量。
* 正例:接口方法签名:void f();
* 接口基础常量表示:String COMPANY="alibaba";
* 反例:接口方法定义:public abstract void f();
* 说明:JDK8中接口允许有默认实现,那么这个default方法,是对所有实现类都有价值的默认实现。
*
* 13.接口和实现类的命名有两套规则:
* 对于Service和DAO类,基于SOA的理念,暴露出来的服务一定是接口,内部的实现类用Impl的后缀与接口区别。
* 如果是形容能力的接口名称,取对应的形容词做接口名(通常是-able的形式)。
* 正例:CacheServiceImpl实现CacheService接口。
* AbstractTranslator实现Translatable.
*
* 14.枚举类名建议带上Enum后缀,枚举成员名称需要全大写,单词间用下划线隔开。
* 说明:枚举其实就是特殊的常量类,且构造方法被默认强制是私有。
* 正例:枚举名字:DealStatusEnum,成员名称:SUCCESS / UNKNOWN_REASON.
(二)常量定义
* 1.不允许出现任何魔法值(即未经定义的常量)直接出现在代码中。
* 反例: String key="Id#taobao_"+tradeId; cache.put(key,value);
* 2.Long或long初始赋值时,必须使用大写的L,不能是小写的l。小写容易跟数字1混淆,造成误解。
* 说明:Long a=2l;不容易看出写的是数字21,还是Long型的2
* 3.不要使用一个常量类维护所有常量,应该按常量功能进行归类,分开维护。
* 如:缓存相关的常量放在类:CacheConsts下,系统配置相关的常量放在类:ConfigConnsts下
* 说明:大而全的常量类,非得使用查找功能才能定位到修改的常量,不利于理解和维护。
* 4.常量的服用层次有五层:跨应用共享常量,应用内共享常量,子工程内共享常量,包内共享常量,类内共享常量。
* 1.跨应用共享常量:放置在第二方库中,通常是client.jar中的constant目录下。
* 2.应用内共享常量:放置在一方库的modules中的constant目录下。
* 反例:易懂变量也要统一定义成应用内共享常量。两位工程师在两个类中分别定义了表示"是"的变量。
* 类A中:public static final String YES="yes";
* 类B中:public static final String YES="Y";
* A.YES.equals(B.YES),预期是true,但实际返回为false,导致线上问题。
* 3.子工程内部共享常量:即在当前子工程的constant目录下。
* 4.包内共享常量:即在当前包下单独的constant目录下。
* 5.类内共享常量:直接在类内部private static final定义。
*
* 5.推荐如果变量值仅在一个范围内变化d用Enum类。如果还带有名称之外的延伸属性,必须使用Enum类,下面例子中的数字就是延伸信息,表示星期几。
* 正例:publicEnum(MONDAY(1),TUESDAY(2),WEDNESDAY(3),THURSDAY(4),FRIDAY(5),SATURDAY(6),SUNDAY(7))
* 11.库名与应用d名称尽量一致。
* 12.如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。
* 13.字段允许适当冗余,以提高性能,但是必须考虑数据同步的情况。冗余字段应遵循:
* 1.不是频繁修改的字段。
* 2.不是varchar超长字段,更不能是text字段。
* 正例:商品类目名称使用频率高,字段长度短,名称基本一成不变,可在相关联的表中冗余存储类目名称,避免关联查询。
*
*
* 14.Service/DAO层方法命名规约
*
* 1.获取单个对象的方法用get做前缀。
* 2.获取多个对象的方法用list做前缀。
*