研发代码管理规范.doc

代码规范 (一) 命名风格 1、【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元 符号结束。 反例：_name / __name / $Object / name_ / name$ / Object$ 建议：最好不使用下划线和美元符号；常量可使用下划线，但不能放在开头和结 尾 2、【强制】代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文 的方式。 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯 拼音命名方式也要避免采用。 正例：alibaba / taobao / youku / hangzhou 等国际通用的名称，可视同英 文。 反例：DaZhePromotion [打折] / getPingfenByName() [评分]/int 某变量 = 3 3、【强制】类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例 外：DO / BO / DTO / VO / AO 说明：DO Domain Object 领域对象：从现实世界抽象出来的业务实体。 ????BO Business Obejct 业务对象：面向业务建立的实体，包含多个PO或VO。 ????DTO Data Transfer Object 数据传输对象：展示层和服务层之间的数据传输建 立的实体。 ????VO Value Object（还有叫View Object）值对象：仅包含数据，不包含业务逻 辑的对象，通常用于页面显示。PO Persustan Object 持久对象：对应数据库的 对象，与数据库字段一一对应。 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion 建议：约定俗成的名称或缩写可以例外 4、【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风 格，必须遵从驼峰形式，包括接口名。 正例：localValue / getHttpMessage() / inputUserId 建议：约定俗成的名称或缩写可以例外；ID为简写，id和ID均可以 5、【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不 要嫌名字长。 正例：MAX_STOCK_COUNT 反例：MAX_COUNT 6、【强制】抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它 要测试的类的名称开始，以 Test 结尾。 建议：抽象类命名只使用 Abstract 开头，因为很多业务基类也是以 Base 开头 的 7、【强制】中括号是数组类型的一部分，数组定义如下：String[] args; 反例：使用String args[]的方式来定义。 8、【强制】POJO 类中布尔类型的变量，都不要加is，否则部分框架解析会引起序 列化错误。 反例：定义为基本数据类型Boolean isDeleted；的属性，它的方法也是 isDeleted()，RPC框架在反向解析的时候，“以为”对应的属性名称是 deleted，导致属性获取不到，进 而抛出异常。 9、【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。 包名统一使用单数形 式，但是类名如果有复数含义，类名可以使用复数形式。 正例：应用工具类包名为 com.alibaba.open.util、类名为 MessageUtils（此规 则参考spring 的框架结构） 10、【强制】杜绝完全不规范的缩写，避免望文不知义。 反例：AbstractClass “缩写”命名成 AbsClass；condition“缩写”命名成 condi，此类随意缩写严重 ????降低了代码的可阅读性。 11、建议：英文中的缩写有惯例，去掉元音留下辅音即可，不能乱缩写，但约定俗成 的缩 写可以例外 12、【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量 完整的单词组合来表达其意。 正例：从远程仓库拉取代码的类命名为 PullCodeFromRemoteRepository。 反例：变量 int a; 的随意命名方式。 13、【推荐】如果模块、接口、类、方法使用了设计模式，在命名时体现出具体模 式。 说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。 正例：public class OrderFactory; ??????public class LoginProxy; ??????public class ResourceObserver