前言

《阿里巴巴Java开发手册》一直深受Java开发爱好者和业界人士的认可，里面提出了许多宝贵的开发经验和建议，相信会对大家有很多的帮助。

但是所谓尽信书不如无书，需要对提到的规范有自己的思考和认同后，这本手册才能够对自己起到更大的帮助。

小弟不才，只是从个人观点谈谈对于这本手册阅读的理解，期望可以持续更新。

编程规约篇

1.【强制】代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。

赞同，可以强制遵守。首先实际代码开发时确实可以这样去做，但这条规范应该是业内同行的共识了，而且以下划线和美元符号开始和结束并不会带来什么其他的好处。

2.【强制】所有编程相关的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。

赞同，可以强制遵守。用纯英文表达释义更容易理解，拼音或者拼音与英文结合，还要考虑多音字的可能性，也不太好理解。

3.【强制】类名使用UpperCamelCase风格，但以下情形例外:DO/BO/DTO/VO/AO/ PO / UID 等。

赞同，可以强制遵守。驼峰式命名这个基本已经是共识了，但关于DO,BO等，其实项目中有人喜欢写Bo,有人先写BO,我个人感觉更倾向于两个都大写，这些其实是一些专用术语的缩写，所以都大写是比较合适的，比如DTO，其实是 Data Transfer Object的缩写。

4.【强制】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格。

赞同，可以强制遵守。基本都是业内共识了。

【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

赞同，可以强制遵守。全部大写，单词间下划线隔开，基本都是共识了，看到过部分代码因为考虑到长度问题，使用了一些缩写来表达，我个人不是很喜欢，属于宁可长一些，但更喜欢可读性强一些的开发者。

【强制】抽象类命名使用Abstract或Base开头;异常类命名使用Exception结尾;测试类命名以它要测试的类的名称开始，以 Test 结尾。

赞同，可以强制遵守。这样理解会更加清晰一些。

【强制】类型与中括号紧挨相连来表示数组。

赞同，可以强制遵守。这样看起来会更加的直观清晰，手册中提到的反例是在main函数的入参中，使用String args[]来定义。我看了下目前IDEA在自动生成main函数时已经是String[] args这种风格了。

【强制】POJO类中的任何布尔类型的变量，都不要加is前缀，否则部分框架解析会引起序列化错误。

有待考究，待补充，手册中给的反例是定义为基本数据类型 Boolean isDeleted的属性，方法也是isDeleted()，框架在反向解析时，会以为对应的属性名称是deleted，导致属性获取不到，进而抛出异常。

那么是哪些框架会出现这些问题呢，现在是否仍然有这些问题，这个有一定历史感的规范是否仍要遵守，毕竟我觉得加上is后，如果是布尔类型，我会更好理解一些，也可以和数据库中的命名一一对应。

9.【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。

到类名之前的部分赞同，可以强制遵守。关于类名有复数含义，可以用复数形式，这个困扰的主要是为什么类名会有复数含义呢，类代表的应该就是一个功能和属性的集合，按我的理解来说，应该是不具备复数含义的。

10.【强制】避免在子父类的成员变量之间、或者不同代码块的局部变量之间采用完全相同的命名，使可读性降低。

基本赞同，可以遵守，如果是代表同一个意思，用一个变量名表达，可读性会更好，管理维护也在一处地方。

11.【强制】杜绝完全不规范的缩写，避免望文不知义。

强烈赞同。最怕代码中遇到不知所以的缩写，有时可能还没注释。

12.【推荐】为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达。

基本赞同，让代码具有自解释的能力，通过阅读变量名就知道具体是用来做什么用的。

13.【推荐】在常量与变量的命名时，表示类型的名词放在词尾，以提升辨识度。

赞同，可以强制遵守。日常也是这么做的。

14.【推荐】如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。

赞同，可以强制遵守。可以降低沟通成本，快速知道具体的作用。

【推荐】接口类中的方法和属性不要加任何修饰符号(public 也不要加)，保持代码的简洁性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，确定与接口方法相关，并且是整个应用的基础常量。

基本赞同。感觉加一下public也无妨，不过接口里的默认都是public，不加确实也可以，接口一般是提供出去的API，一定要写好注释，否则真不知道你这个接口该怎么用。一般确实也不在接口里定常量，都会有单独的常量类来维护。

16-1. 【强制】对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部的实现类用 Impl 的后缀与接口区别。

赞同，可以强制遵守。日常都是这么做的，更好区分一些。

16-2. 【推荐】如果是形容能力的接口名称，取对应的形容词为接口名(通常是–able 的形容词)。

感觉说的有道理，这个平时用的比较少，一般声明的接口，代表的是一堆动作，命名上更偏向于名词，比如XXXhandler。

【参考】枚举类名带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。

赞同，可以强制遵守。日常就是这样做的，可读性更好一些。

主要讲了一些命名规范，具体见手册。

个人感觉，可以参考下，每个组有自己的一套规范即可，不需要强制和手册保持一致。目前来说，一般习惯把持久层，数据库表成为XXXPO,展示对象叫VO，系统内的传输对象叫做BO，跨系统的数据传输对象叫做DTO。