Java代码规范
命名约定
类名采用大驼峰，一般为名词，如ArrayList
方法名称采用小驼峰，一般为动词。 例如，ArrayList的isEmpty ()。
变量采用小驼峰
的字符都是大写的，单词之间用下划线连接
包名称以小写字母统一，点分隔之间只有一个自然意义的英语单词，例如java.util.concurrent，都是一个单词。 包名称统一为单数，如果类名有多个含义，则可以使用复数形式
抽象类以Abstract或Base开头； 异常类以Exception结尾测试类名称以测试类名称开头，以Test结尾
要定义数组，如int[]，请后跟类型和大括号
枚举类名加上枚举后缀，使枚举成员名称全部大写，并用下划线将单词连接起来
在复合词义下，尽量使用完整的单词组合进行命名。 例如，KeyboardShortcutsHandler、AtomicReferenceFieldUpdater
常数
常数是范围内不变的值，一般用final关键字限定，由范围区分，分为全局常数、类内常数、局部常数。 全局常量是类的公共静态属性，用公共静态final限定。 类常量是专用的静态属性，由私有静态文件限定。 局部常量包括方法常量和参数常量，前者是在方法或代码块中定义的常量，后者在定义表单参数时添加final标志，指示不能更改此参数的值。 全局常数和类内常数是最主要的常数表示形式，它们的命名方式比较特殊，采用字母全部大写，单词之间划线的方式。 局部常数以小驼峰的形式就可以了。
常量拒绝使用魔法值。 魔法值，也就是“共识水平”的常数，直接以具体的数值或文字出现在代码中。 这些未知的魔法值会严重影响代码的可读性和可维护性。
板栗：
publicvoidgetonlinepackagecourse (长打包geid，长用户id ) {
if (包id==3) {
logger.error (在线课程，在线上看不到)；
返回；
}
//其他逻辑处理
packagecourseonline=packageservice.getbyteacherid (userid；
if(online.getpackageid ()==2) {
logger.error (未审查课程)；
返回；
}
//其他逻辑处理
}
在上述示例代码中，用手捏的2和3分别表示未审查课程和在线课程，只有两个数字，似乎很容易记住。 但实际上除了2和3两种状态外，1、4、5分别表示新建、审核不合格、审核不合格。 团队规模小的时候，通过口碑才能记住这五个数字的意思。 虽然初期还有零星注释，但如果你开得很轻，也可以省去注释。 现实是残酷的，队伍迅速扩大后，授课状态的个数也在逐渐增加。 新开发的新功能模块在线开发新功能模块时，将“考核合格”和“未经考核的课程”对应的数字颠倒过来，导致课程展示错误，导致用户大量投诉。 随着APP应用越来越复杂，这些魔法值已成为整个后台服务代码的噩梦。 架构师终于决定重建系统，并以适当的命名方法将这些魔法值定义为全局常数。 使用枚举类定义课程类型。 示例代码如下：
公共枚举计算类型枚举{
//*
允许官方和讲师编制和运营
*/
video_course(1，“录像课程”)、
//*
*只允许编制和运营官方。 初始化需要设定合理的注册人数上限
*/
live_course(2，'实时课程')、
//*
*只允许编制和运营官方
*/
offline_course(3，'在线课程')；
私密int seq；
私有字符串磁盘；
coursetypeenum(intseq，字符串磁盘) {
this.seq=seq；
this.desc=desc；
}
公共int get seq () {
返回seq；
}
公共字符串获取桌面
返回磁盘；
}
}
上述示例代码将课程类型分为三类：录制课程、现场课程和在线课程。 枚举类型是一个几乎固定的全局常量，使用频率高，范围广，因此必须在枚举常量中添加明确的注释，包括业务信息和注意事项。 将课程状态分为新课程、未审查课程、通过审查、通过审查和删除的五种状态。 考虑到后续课状态被进一步添加，状态没有扩展信息，用无法实例化的抽象类的全局常量表示课状态。 示例代码为以下：
p
ublic abstract class BaseCourseState {public static final int NEW_COURSE = 1;
public static final int UNAUTHED_COURSE = 2;
public static final int PASSED_COURSE = 3;
public static final int NOT_PASSED_COURSE = 4;
public static final int DELETED_COURSE = 5;
}
使用重构后的常量修改原有的魔法值：
public void getPackageCourse(Long packageId, Long userId) {
if (packageId == CourseTypeEnum.OFFLINE_COURSE.getSeq()) {
logger.error("线下课程，无法在线观看");
return;
}
VideoCourse course = packageService.getByTeacherId(userId);
if (course.getState() == BaseCourseState.UNAUTHED_COURSE) {
logger.error("未审核课程");
return;
}
}
某些公认的字面常量是不需要预定义的，如 for(int i = 0;...)这里的0是可以直接使用的。
true和false也可以直接使用，但是如果具备了特殊的含义，就必须定义有意义的名称。
变量
一般情况下变量的命名需要满足小驼峰格式，命名体现业务含义即可。存在一种特殊情况，在定义类成员变量时，特别是在POJO类中，针对布尔类型的变量，命名不要加is前缀，否则部分框架解析会引起序列化错误。例如，定义标识是否删除的成员变量为Boolean isDeleted，它的getter方法也是isDeleted()，框架在反向解析的时候， “误以为"对应的属性名称是deleted，导致获取不到属性，进而抛出异常。但是在数据库建表中，推荐表达是与否的值采用is_xxx的命名方式，针对此种情况，需要在中设置，将数据表中的is_xxx字段映射到POJO类中的属性Xxx。
展示风格
缩进、空格、空行
采用4个空格缩进
任何二目、三目运算符的左右两边都必须加一个空格
注释的双斜线与注释内容之间有且仅有一个空格
方法参数在定义和传入时，多个参数逗号后边必须加空格
没有必要增加若干空格使变量的赋值等号与上一行对应位置的等号对齐
如果是大括号内为空，则简洁地写成{}即可，大括号中间无须换行和空格
左右小括号与括号内部的相邻字符之间不要出现空格
左大括号前需要加空格
换行与高度
单行字符不超过120个，超出则需换行，换行遵循如下规约：
第二行相对第一行缩进4个空格，从第三行开始，不再继续缩进
运算符与下文一起换行
方法调用的点符号与下文一起换行
方法调用中的多个参数需要换行时，在逗号后换行
在括号前不要换行
单个方法的总行数不超过80行。
除注释之外，方法签名、左右大括号、方法内代码、空行、回车及任何不可见字符的总行数，不超过80行。为什么是80行？心理学认为人对事物的印象通常不能超过3这个魔法数，三屏是人类短期记忆的极限，而80行在一般显示器上是两屏半的代码量。另外，通过对阿里代码抽样调查显示，只有不到5%的方法才会超过80行，而这些方法通常都有明显的优化空间。
控制语句
在 if、else、for、while、do-while等语句中必须使用大括号。即使只有一行代码，也需要加上大括号
在条件表达式中不允许有赋值操作，也不允许在判断表达式中出现复杂的逻辑组合。对于复杂的逻辑运算，可以赋值给一个具有业务含义的布尔变量。
// 不易于理解
if ((file.open(fileName, "w") != null) && (...) ||!(...)){
...
}
// 易于理解
final boolean existed = (file.open(fileName, "w") != null) && (...) ||!(...);
if (existed) {
...
}
多层嵌套不能超过3层。对于超过3层的if-else代码，可以使用卫语句、策略模式、状态模式来实现
卫语句示例：
public void today () {
if (isBusy()) {
System.out.println("change time.");
return;
}
if (isFree()) {
System.out.println("go to travel.");
return;
}
System.out.println("stay at home.");
return;
}
避免采用反逻辑运算符。如if (x < 1)而不是if (!(x >= 1))
代码注释
注释三要素
Nothing is strange
我们提倡写注释，然后才是写精简。
Less is more
从代码可读性及维护成本方面来讲,代码中的注释一定是精华中的精华。首先，真正好的代码是自解释的，准确的变量命名加上合理的代码逻辑，无须过多的文字说明就足以让其他工程师理解代码的功能。如果代码需要大量的注释来说明解释，那么工程师应该思考是否可以优化代码表现力。
Advance with the times
任何对代码的修改，都应该同时修改注释。
注释格式
Javadoc注释
类、类属性和类方法的注释必须遵循Javadoc规范，使用文档注释(/*/)的格式。
对枚举的注释是必需的。有人觉得枚举通常带了String name属性，已经简要地说明了这个枚举属性值的意思,此时注释是多余的。其实不然，因为:
注释的内容不仅限于解释属性值的含义，还可以包括注意事项、业务逻辑。如果在原有枚举类上新增或修改一个属性值，还需要加上创建和修改时间，让使用者零成本地知道这个枚举类的所有意图
枚举类的删除或者修改都存在很大的风险。不可直接删除过时属性，需要标注为过时，同时注释说明过时的逻辑考虑和业务背景
简单注释
简单注释包括单行注释和多行注释。此类注释不允许写在代码后方，必须写在代码上方，这是为了避免注释的参差不齐，导致代码版式混乱。双画线注释往往使用在方法内部，此时的注释是提供给程序开发者、维护者和关注方法细节的调用者查看的。因此，注释的作用更应该是画龙点睛的，通常添加在非常必要的地方，例如复杂算法或需要警示的特殊业务场景等。