没有合适的资源?快使用搜索试试~ 我知道了~
首页唯品会Java开发手册v1.0版
资源详情
资源评论
资源推荐

《唯品会Java开发手册》1.0版
1. 概述
《阿里巴巴Java开发手册》,是首个对外公布的企业级Java开发手册,对整
个业界都有重要的意义。
《唯品会Java开发手册》在其基础上,结合唯品会的内部经验,参考
《Clean Code》、《Effective Java》等重磅资料,增补了一些我们认为价值
较大的条目,同时删减了一些相对没那么重要,或不通用的规则,让规范更
精炼易记。
感谢阿里的授权修改。
2. 规范正文
1. 命名规约
2. 格式规约
3. 注释规约
4. 方法设计
5. 类设计
6. 控制语句
7. 基本类型
8. 集合处理
9. 并发处理
10. 异常处理
11. 日志规约
12. 其他设计
如需全文pdf版,请运行merge.sh生成。
3. 附录
• Eclipse/Intellij 格式模板

• 阿里手册的增补与删减记录
4. 参考资料
• 《Clean Code》
• 《Effective Java 2nd》
• 《SEI CERT Oracle Coding Standard for Java》(在线版)
• Sonar代码检查规则
\n
(一) 命名规约
Rule 1. 【强制】禁止拼音缩写,禁止拼音/拼音缩写与英文的混合,尽量不
用拼音
Rule 2. 【强制】禁止使用非标准的缩写
Rule 3. 【强制】禁用其他编程语言风格的前缀和后缀
在其它编程语言中使用的特殊前缀或后缀,如
_name , name_ , mName , i_n
ame ,在Java中都不建议使用。
Rule 4. 【推荐】包名全部小写。点分隔符之间尽量只有一个英语单词,即使
有多个单词也不使用下划线或大小写分隔
反例:
DZ[
打折
] / DaZhePromotion [
打折
] / getPFByName() [
评
分
]
反例:
AbstractClass
缩
写
成
AbsClass
;
condition
缩
写
成
condi
。

• Sonar-120:Package names should comply with a naming convention
Rule 5. 【强制】类名与接口名使用UpperCamelCase风格,遵从驼峰形式
Tcp, Xml等缩写也遵循驼峰形式,可约定例外如:DTO/ VO等。
• Sonar-101:Class names should comply with a naming convention
• Sonar-114:Interface names should comply with a naming convention
Rule 6. 【强制】方法名、参数名、成员变量、局部变量使用
lowerCamelCase风格,遵从驼峰形式
• 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 7. 【强制】常量命名全部大写,单词间用下划线隔开。力求语义表达完
整清楚,不要嫌名字长
正例:
com.vip.javatool
反例:
com.vip.java_tool, com.vip.javaTool
正例:
UserId / XmlService / TcpUdpDeal / UserVO
反例:
UserID / XMLService / TCPUDPDeal / UserVo
正例:
localValue / getHttpMessage();
正例:
MAX_STOCK_COUNT
反例:
MAX_COUNT

例外:当一个static final字段不是一个真正常量,比如不是基本类型时,不需
要使用大写命名。
• Sonar-115:Constant names should comply with a naming convention
Sonar会先判定是否基本类型
• Sonar-308:Static non-final field names should comply with a naming
convention
Rule 8. 【推荐】命名的好坏,在于其“模糊度”
1)如果上下文很清晰,局部变量可以使用 list 这种简略命名, 否则应该
使用 userList 这种更清晰的命名。
2)禁止 a1, a2, a3 这种带编号的没诚意的命名方式。
3)方法的参数名叫 bookList ,方法里的局部变量名叫 theBookList 也
是很没诚意。
4)如果一个应用里同时存在 Account、AccountInfo、AccountData 类,或
者一个类里同时有 getAccountInfo()、getAccountData() , save()、
store() 的函数,阅读者将非常困惑。
5) callerId 与 calleeId , mydearfriendswithA 与 mydearfriendswi
thB 这种拼写极度接近,考验阅读者眼力的。
Rule 9. 【推荐】如果使用到了通用的设计模式,在类名中体现,有利于阅读
者快速理解设计思想
//
与
其
private static final Logger LOGGER = Logger.getLogger(MyClass.class);
//
不如
private static final Logger logger = Logger.getLogger(MyClass.class);
private static Logger logger = Logger.getLogger(MyClass.class);
正例:
OrderFactory
,
LoginProxy
,
ResourceObserver

Rule 10. 【推荐】枚举类名以Enum结尾; 抽象类使用Abstract或Base开
头;异常类使用Exception结尾;测试类以它要测试的类名开始,以Test结
尾
• Sonar-3577:Test classes should comply with a naming convention
• Sonar-2166:Classes named like "Exception" should extend "Exception"
or a subclass
Rule 11. 【推荐】实现类尽量用Impl的后缀与接口关联
Rule 12. 【强制】POJO类中布尔类型的变量名,不要加is前缀,否则部分
框架解析会引起序列化错误
反例:Boolean isSuccess的成员变量,它的GET方法也是isSuccess(),部
分框架在反射解析的时候,“以为”对应的成员变量名称是success,导致出
错。
Rule 13. 【强制】避免成员变量,方法参数,局部变量重名复写,避免引起
混淆
• 类的私有成员变量名,不与父类的成员变量重名
• 方法的参数名/局部变量名,不与类的成员变量重名(getter/setter例外)
下面错误的地方,在编译时都是合法的,但给阅读者带来极大的障碍。
正例:
DealStatusEnum
,
AbstractView
,
BaseView
,
TimeoutException
,
UserServiceTest
正例:
CacheServiceImpl
实现
CacheService
接⼝。
public class A {
int foo;
}
public class B extends A {
int foo; //WRONG
int bar;
剩余63页未读,继续阅读












安全验证
文档复制为VIP权益,开通VIP直接复制

评论0