前言
目前正在出一个阿里巴巴Java开发手册
系列教程, 篇幅会较多, 喜欢的话,给个关注❤️ ~
在日常开发中,好的编码习惯和代码规范有助于提高代码可读性
,提升团队协作效率
,还利于维护与扩展
,在某些情况下还有利于优化性能
。今天就带着大家一起学习下手册中的内容,学习下Java
开发中的编码规范。
好了, 废话不多说直接开整吧~
流程控制
【强制】
在一个switch
块内,每个case
要么通过continue/break/return
等来终止,要么注释说明程序将继续执行到哪一个case
为止;在一个switch
块内,都必须包含一个default
语句并且放在最后,即使它什么代码也没有。
说明:注意 break
是退出switch
语句块,而 return
是退出方法体。
【强制】
当switch
括号内的变量类型为String
并且此变量为外部参数时,必须先进行 null判断。
反例:如下的代码输出是什么?
java
public class SwitchString {
public static void main(String[] args) {
method(null);
}
public static void method(String param) {
switch (param) {
// 肯定不是进入这里
case "sth":
System.out.println("it's sth");
break;
// 也不是进入这里
case "null":
System.out.println("it's null");
break;
// 也不是进入这里
default:
System.out.println("default");
}
}
}
-
【强制】
在if/else/for/while/do
语句中必须使用大括号。 说明:即使只有一行代码,禁止不采用大括号的编码方式:if (condition) statements;
-
【强制】
三目运算符condition?
表达式 1 : 表达式 2 中,高度注意表达式 1 和 2 在类型对齐时,可能抛出因自动拆箱导致的 NPE 异常。
说明:以下两种场景会触发类型对齐的拆箱操作: 1) 表达式 1 或表达式 2 的值只要有一个是原始类型。 2) 表达式 1 或表达式 2 的值的类型不一致,会强制拆箱升级成表示范围更大的那个类型。
反例:
java
Integer a = 1;
Integer b = 2;
Integer c = null;
Boolean flag = false;
// a*b 的结果是 int 类型,那么 c 会强制拆箱成 int 类型,抛出 NPE 异常
Integer result=(flag? a*b : c);
【强制】
在高并发场景中,避免使用"等于"判断作为中断或退出的条件。 说明:如果并发控制没有处理好,容易产生等值判断被"击穿"的情况,使用大于或小于的区间判断条件来代替。
反例:判断剩余奖品数量等于 0 时,终止发放奖品,但因为并发处理错误导致奖品数量瞬间变成了负数,这样的话,活动无法终止。
-
【推荐】
当某个方法的代码行数超过10
行时,return / throw
等中断逻辑的右大括号后加一个空行。 说明:这样做逻辑清晰,有利于代码阅读时重点关注。 -
【推荐】
表达异常的分支时,少用if-else
方式,这种方式可以改写成:
java
if (condition) {
...
return obj;
}
// 接着写 else 的业务逻辑代码;
说明:如果非使用 if()...else if()...else...
方式表达逻辑,避免后续代码维护困难,请勿超过 3 层。 正例:超过 3 层的 if-else
的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现,其中卫语句
示例如下:
java
public void findBoyfriend (Man man){
if (man.isUgly()) {
System.out.println("本姑娘是外貌协会的资深会员");
return;
}
if (man.isPoor()) {
System.out.println("贫贱夫妻百事哀");
return;
}
if (man.isBadTemper()) {
System.out.println("银河有多远,你就给我滚多远");
return;
}
System.out.println("可以先交往一段时间看看");
}
【推荐】
除常用方法(如 getXxx/isXxx)等外,不要在条件判断中执行其它复杂的语句,将复杂逻辑判断的结果赋值给一个有意义的布尔变量名,以提高可读性。 说明:很多 if 语句内的逻辑表达式相当复杂,与、或、取反混合运算,甚至各种方法纵深调用,理解成本非常高。如果赋值一个非常好理解的布尔变量名字,则是件令人爽心悦目的事情。
正例:
java
// 伪代码如下
final boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}
反例:
java
public final void acquire ( long arg){
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) {
selfInterrupt();
}
【推荐】
不要在其它表达式(尤其是条件表达式)中,插入赋值语句。 说明:赋值点类似于人体的穴位,对于代码的理解至关重要,所以赋值语句需要清晰地单独成为一行。
反例:
java
public Lock getLock(boolean fair) {
// 算术表达式中出现赋值操作,容易忽略 count 值已经被改变
threshold = (count = Integer.MAX_VALUE) - 1;
// 条件表达式中出现赋值操作,容易误认为是 sync==fair
return (sync = fair) ? new FairSync() : new NonfairSync();
}
10.【推荐】
循环体中的语句要考量性能,以下操作尽量移至循环体外处理,如定义对象、变量、获取数据库连接,进行不必要的 try-catch
操作(这个 try-catch
是否可以移至循环体外)。
11.【推荐】
避免采用取反逻辑运算符。 说明:取反逻辑不利于快速理解,并且取反逻辑写法必然存在对应的正向逻辑写法。 正例:使用 if (x < 628)
来表达 x 小于 628。 反例:使用if (!(x >= 628))
来表达 x 小于 628。
12.【推荐】
接口入参保护,这种场景常见的是用作批量操作的接口。 反例:某业务系统,提供一个用户批量查询的接口,API 文档上有说最多查多少个,但接口实现上没做任何保护,导致调用方传了一个 1000 的用户 id 数组过来后,查询信息后,内存爆了。
13.【参考】
下列情形,需要进行参数校验: 1) 调用频次低的方法。 2) 执行时间开销很大的方法。此情形中,参数校验时间几乎可以忽略不计,但如果因为参数错误导致 中间执行回退,或者错误,那得不偿失。 3) 需要极高稳定性和可用性的方法。 4) 对外提供的开放接口,不管是 RPC/API/HTTP
接口。 5) 敏感权限入口。
14.【参考】
下列情形,不需要进行参数校验: 1) 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查。 2) 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道,参数错误不太可能到底层才会暴露问题。一般 DAO
层与 Service
层都在同一个应用中,部署在同一台服务器中,所以 DAO 的参数校验,可以省略。 3) 被声明成 private 只会被自己代码所调用的方法,如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题,此时可以不校验参数。
结束语
下节给大家讲代码注释
规范~
本着把自己知道的都告诉大家,如果本文对有所帮助,点赞+关注
鼓励一下呗~
阿里巴巴Java开发手册相关文章
MybatisPlus教程相关文章
往期Nginx教程相关文章
往期Docker教程相关文章
往前Shell脚本编程相关文章
- 一起来学Shell脚本编程(一)
- 一起来学Shell脚本编程(二)
- 一起来学Shell脚本编程(三)
- 一起来学Shell脚本编程(四)
- 一起来学Shell脚本编程(五)
- 一起来学Shell脚本编程(六)
- 一起来学Shell脚本编程(七)
往期Linux相关文章
- 一起来学Linux命令(一)
- 一起来学Linux命令(二)
- 一起来学Linux命令(三)
- 一起来学Linux命令(四)
- 一起来学Linux命令(五)
- 一起来学Linux命令(六)
- 一起来学Linux命令(七)
- 一起来学Linux命令(八)
- 一起来学Linux命令(九)
- 一起来学Linux命令(十)
往期面试题相关文章
- 查漏补缺第一期(Redis相关)
- 查漏补缺第二期(synchronized & 锁升级)
- 查漏补缺第三期(分布式事务相关)
- 查漏补缺第四期(Mysql相关)
- 查漏补缺第五期(HashMap & ConcurrentHashMap)
- 查漏补缺第六期(京东一面)
- 查漏补缺第七期(美团到店一面)
- 查漏补缺第八期(阿里一面)
- 查漏补缺第九期(阿里二面)
- 查漏补缺第十期(网易实习一面)
- 查漏补缺第十一期(网易实习二面)
- 查漏补缺第十二期(网易实习三面)
- 查漏补缺第十三期(滴滴实习一面)
- 查漏补缺第十四期(滴滴实习二面)
- 查漏补缺第十五期(华为一面)
- 查漏补缺第十六期(华为二面)
- 查漏补缺第十七期(华为三面)
- 查漏补缺第十八期(你了解class文件吗)
项目源码(源码已更新 欢迎star⭐️)
往期设计模式相关文章
- 一起来学设计模式之认识设计模式
- 一起来学设计模式之单例模式
- 一起来学设计模式之工厂模式
- 一起来学设计模式之建造者模式
- 一起来学设计模式之原型模式
- 一起来学设计模式之适配器模式
- 一起来学设计模式之桥接模式
- 一起来学设计模式之组合模式
- 一起来学设计模式之装饰器模式
- 一起来学设计模式之外观模式
- 一起来学设计模式之享元模式
- 一起来学设计模式之代理模式
- 一起来学设计模式之责任链模式
- 一起来学设计模式之命令模式
- 一起来学设计模式之解释器模式
- 一起来学设计模式之迭代器模式
- 一起来学设计模式之中介者模式
- 一起来学设计模式之备忘录模式
- 一起来学设计模式之观察者模式
- 一起来学设计模式之状态模式
- 一起来学设计模式之策略模式
- 一起来学设计模式之模板方法模式
- 一起来学设计模式之访问者模式
- 一起来学设计模式之依赖注入模式
设计模式项目源码(源码已更新 欢迎star⭐️)
Kafka 专题学习
- 一起来学kafka之Kafka集群搭建
- 一起来学kafka之整合SpringBoot基本使用
- 一起来学kafka之整合SpringBoot深入使用(一)
- 一起来学kafka之整合SpringBoot深入使用(二)
- 一起来学kafka之整合SpringBoot深入使用(三)
项目源码(源码已更新 欢迎star⭐️)
ElasticSearch 专题学习
项目源码(源码已更新 欢迎star⭐️)
往期并发编程内容推荐
- Java多线程专题之线程与进程概述
- Java多线程专题之线程类和接口入门
- Java多线程专题之进阶学习Thread(含源码分析)
- Java多线程专题之Callable、Future与FutureTask(含源码分析)
- 面试官: 有了解过线程组和线程优先级吗
- 面试官: 说一下线程的生命周期过程
- 面试官: 说一下线程间的通信
- 面试官: 说一下Java的共享内存模型
- 面试官: 有了解过指令重排吗,什么是happens-before
- 面试官: 有了解过volatile关键字吗 说说看
- 面试官: 有了解过Synchronized吗 说说看
- Java多线程专题之Lock锁的使用
- 面试官: 有了解过ReentrantLock的底层实现吗?说说看
- 面试官: 有了解过CAS和原子操作吗?说说看
- Java多线程专题之线程池的基本使用
- 面试官: 有了解过线程池的工作原理吗?说说看
- 面试官: 线程池是如何做到线程复用的?有了解过吗,说说看
- 面试官: 阻塞队列有了解过吗?说说看
- 面试官: 阻塞队列的底层实现有了解过吗? 说说看
- 面试官: 同步容器和并发容器有用过吗? 说说看
- 面试官: CopyOnWrite容器有了解过吗? 说说看
- 面试官: Semaphore在项目中有使用过吗?说说看(源码剖析)
- 面试官: Exchanger在项目中有使用过吗?说说看(源码剖析)
- 面试官: CountDownLatch有了解过吗?说说看(源码剖析)
- 面试官: CyclicBarrier有了解过吗?说说看(源码剖析)
- 面试官: Phaser有了解过吗?说说看
- 面试官: Fork/Join 有了解过吗?说说看(含源码分析)
- 面试官: Stream并行流有了解过吗?说说看