阿里java编码规范（三）控制语句，注释规约

蔚落 2022-06-14 07:51 214阅读 0赞

最近阿里出了一个java开发手册，里面涉及到很多工作规范的地方，有很多借鉴和参考的作用，也可以给新入行的工程师作为参考。

下载地址是在：http://techforum-img.cn-hangzhou.oss-pub.aliyun-inc.com/阿里巴巴Java开发手册v1.2.0.pdf

(七) 控制语句

1.  【强制】在一个 switch 块内,每个 case 要么通过 break/return 等来终止,要么注释说明程序将继续执行到哪一个  case 为止;在一个 switch 块内,都必须包含一个 default 语句并且放在最后,即使它什么代码也没有。
2.  【强制】在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码,避免使用单行的形式:if (condition) statements;
3.  【推荐】表达异常的分支时,少用 if-else 方式,这种方式可以改写成:
    
    if (condition) \{...
    
    return obj;\}
    
    // 接着写 else 的业务逻辑代码;  
    说明:如果非得使用 if()...else if()...else...方式表达逻辑,【强制】避免后续代码维
    
    护困难,请勿超过 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 to learn Alibaba Java Coding Guideline.”);
    
    return;\}
4.  【推荐】除常用方法(如 getXxx/isXxx)等外,不要在条件判断中执行其它复杂的语句,将复杂逻辑判断的结果赋值给一个有意义的布尔变量名,以提高可读性。  
    说明:很多 if 语句内的逻辑相当复杂,阅读者需要分析条件表达式的最终结果,才能明确什么样的条件执行什么样的语句,那么,如果阅读者分析逻辑表达式错误呢?

正例:

//伪代码如下  
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);if (existed) \{

...\}

反例:

if ((file.open(fileName, "w") != null) && (...) || (...)) \{...

1.  【推荐】循环体中的语句要考量性能,以下操作尽量移至循环体外处理,如定义对象、变量、
    
    获取数据库连接,进行不必要的 try\-catch 操作(这个 try\-catch 是否可以移至循环体外)。
2.  【推荐】接口入参保护,这种场景常见的是用于做批量操作的接口。
3.  【参考】下列情形,需要进行参数校验:  
    1) 调用频次低的方法。  
    2) 执行时间开销很大的方法。此情形中,参数校验时间几乎可以忽略不计,但如果因为参
    
    数错误导致中间执行回退,或者错误,那得不偿失。  
    3) 需要极高稳定性和可用性的方法。  
    4) 对外提供的开放接口,不管是RPC/API/HTTP接口。5) 敏感权限入口。
4.  【参考】下列情形,不需要进行参数校验:  
    1) 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。  
    2) 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道,参数错误不太可能到底
    
    层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中,部署在同一台服务器中,所以  DAO 的参数校验,可以省略。
    
    3) 被声明成private只会被自己代码所调用的方法,如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题,此时可以不校验参数。

(八) 注释规约

1. 【强制】类、类属性、类方法的注释必须使用 Javadoc 规范,使用/\*\*内容\*/格式,不得使用//xxx 方式。

说明:在 IDE 编辑窗口中,Javadoc 方式会提示相关注释,生成 Javadoc 可以正确输出相应注释;在 IDE 中,工程调用方法时,不进入方法即可悬浮提示方法、参数、返回值的意义,提高阅读效率。

1.  【强制】所有的抽象方法(包括接口中的方法)必须要用 Javadoc 注释、除了返回值、参数、
    
        异常说明外,还必须指出该方法做什么事情,实现什么功能。
          说明:对子类的实现要求,或者调用注意事项,请一并说明。
2.  【强制】所有的类都必须添加创建者和创建日期。
3.  【强制】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释
    
    使用/\* \*/注释,注意与代码对齐。
4.  【强制】所有的枚举类型字段必须要有注释,说明每个数据项的用途。
5.  【推荐】与其“半吊子”英文来注释,不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。  
    反例:“TCP 连接超时”解释成“传输控制协议连接超时”,理解反而费脑筋。
6.  【推荐】代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑等的修改。
    
    说明:代码与注释更新不同步,就像路网与导航软件更新不同步一样,如果导航软件严重滞后,就失去了导航的意义。
7.  【参考】合理处理注释掉的代码。在上方详细说明,而不是简单的注释掉。如果无用,则删除。说明:代码被注释掉有两种可能性:1)后续会恢复此段代码逻辑。2)永久不用。前者如果没有备注信息,难以知晓注释动机。后者建议直接删掉(代码仓库保存了历史代码)。
8.  【参考】对于注释的要求:第一、能够准确反应设计思想和代码逻辑;第二、能够描述业务含义,使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书,注释是给自己看的,即使隔很长时间,也能清晰理解当时的思路;注释也是给继任者看的,使其能够快速接替自己的工作。

10. 【参考】好的命名、代码结构是自解释的,注释力求精简准确、表达到位。避免出现注释的

一个极端:过多过滥的注释,代码的逻辑一旦修改,修改注释是相当大的负担。

反例:

// put elephant into fridge

put(elephant, fridge);  
方法名 put,加上两个有意义的变量名 elephant 和 fridge,已经说明了这是在干什么,语

义清晰的代码不需要额外的注释。

11. 【参考】特殊注释标记,请注明标记人与标记时间。注意及时处理这些标记,通过标记扫描,经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。

1) 待办事宜(TODO):( 标记人,标记时间,\[预计处理时间\])表示需要实现,但目前还未实现的功能。这实际上是一个 Javadoc 的标签,目前的 Javadoc

还没有实现,但已经被广泛使用。只能应用于类,接口和方法(因为它是一个 Javadoc 标签)。

![page19image9568][]

2) 错误,不能工作(FIXME):(标记人,标记时间,\[预计处理时间\])

在注释中用 FIXME 标记某代码是错误的,而且不能工作,需要及时纠正的情况。

(九) 其它

1.  【强制】在使用正则表达式时,利用好其预编译功能,可以有效加快正则匹配速度。
    
    说明:不要在方法体内定义:Pattern pattern = Pattern.compile(规则);
2.  【强制】velocity 调用 POJO 类的属性时,建议直接使用属性名取值即可,模板引擎会自动按规范调用 POJO 的 getXxx(),如果是 boolean 基本数据类型变量(boolean 命名不需要加 is前缀),会自动调用 isXxx()方法。  
    说明:注意如果是 Boolean 包装类对象,优先调用 getXxx()的方法。
3.  【强制】后台输送给页面的变量必须加$!\{var\}——中间的感叹号。说明:如果 var=null 或者不存在,那么$\{var\}会直接显示在页面上。
4.  【强制】注意 Math.random() 这个方法返回是 double 类型,注意取值的范围 0≤x<1(能够取到零值,注意除零异常),如果想获取整数类型的随机数,不要将 x 放大 10 的若干倍然后取整,直接使用 Random 对象的 nextInt 或者 nextLong 方法。
5.  【强制】获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime();说明:如果想获取更加精确的纳秒级时间值,使用 System.nanoTime()的方式。在 JDK8  中,针对统计时间等场景,推荐使用 Instant 类。
6.  【推荐】不要在视图模板中加入任何复杂的逻辑。  
    说明:根据 MVC 理论,视图的职责是展示,不要抢模型和控制器的活。
7.  【推荐】任何数据结构的构造或初始化,都应指定大小,避免数据结构无限增长吃光内存。
8.  【推荐】对于“明确停止使用的代码和配置”,如方法、变量、类、配置文件、动态配置属性等要坚决从程序中清理出去,避免造成过多垃圾。

[page19image9568]: