阿里巴巴Java开发规约第一章-控制语句篇

1.[强制] 在一个switch块内，每个case要么通过break/return等来终止，要么注释说明程序将继续执行到哪一个case为止;在一个switch块内，都必须包含一个default语句并且放在最后，即使空代码。

老四附言:

switch语句块必须有default语句是十分有必要的。比如你想判断处理某个字符串变量分别为”a”、”b”、”c”的case语句，但是万一程序给你传了一个字符”d”进去，如果没有default语句你不就傻逼了吗?有的时候不要觉得某一代码块跟业务或者系统无关就养成了一个”清除无用代码”的”好习惯”。

2.[强制] 在if/else/for/while/do语句中必须使用大括号。即使只有一行代码，避免采用单行的编码方式: if (condition) statements;

老四附言:

一种规范而已，而且加上大括号代码结构特别清晰，老四在此之前也是这么做的，有很多人估计受到过c语言之类的影响，不习惯这么写，即使不这么做，你能做到代码完美的缩进，代码块做到清晰可辨别其实也没什么。

3.[强制] 在高并发场景中，避免使用”等于”判断作为中断或退出的条件。

说明: 如果并发控制没有处理好，容易产生等值判断被”击穿”的情况，使用大于或小于的区间判断条件来代替。

反例: 判断剩余奖品数量等于0时，终止发放奖品，但因为并发处理错误导致奖品数量瞬间变成了负数，这样的话，活动无法终止。

老四附言:

说到这里，老四也来推荐一下这本鼎鼎大名的关于Java并发编程实战的书籍-《Java并发编程实战》，老四最近也在看，这本书会让我们对Java多线程，业务并发有清晰明了深刻的监视。本着分享的精神，为暂时买书有困难的学子提供一下电子版。经济条件尚可请您务必买实体书或者正版电子书支持一下。文末自助获取下载。

4.[推荐] 表达异常的分支时，少用if-else方式，这种方式可以改写成:

说明: 如果非得使用if()…else if()…else…方式表达逻辑， [强制] 避免后续代码维护困难，请勿超过3层。

正例: 超过3层的if-else的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，其中卫语句示例如下:

老四附言:

关于这条规则，以及什么时候卫语句，设计模式中的策略模式、状态模式等基本知识可以参考老四书写的如下文章。

• 《阿里巴巴Java开发手册第三章-单元测试篇》(里面有关于卫语句的讲解及用法)
• 《浅析设计模式第二章之策略模式》
• 《浅析设计模式第十六章之状态模式》

5.[推荐] 除常用方法(如getXxx/isXxx)等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。

说明: 很多if语句内的逻辑相当复杂，阅读者需要分析条件表达式的最终结果，才能明确什么样的条件执行什么样的语句，那么，如果阅读者分析逻辑表达式错误呢？

正例:

反例:

老四附言:

我觉得这条很好，在这之前老四经常看到一大段的逻辑卸载if()里面，需要长时间去理解，包括自己也是这么写的。如孤尽所说，将复杂的逻辑抽象出来，辅以注释供他人阅读，不仅代码整洁，条理清晰。

6.[推荐] 循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变量、获取数据库连接，进行不必要的try-catch操作(这个try-catch是否可以移至循环体外)。

老四附言:

循环体要做的是当前业务自己最纯粹的东西，与之无关的代码或者说循环体的技术支撑都要在体外进行，达到代码高效。

7.[推荐] 避免采用取反逻辑运算符。

说明: 取反逻辑不利于快速理解，并且取反逻辑写法必然存在对应的正向逻辑写法。

正例: 使用if(x < 628)来表达x小于628。

反例: 使用if(!(x >= 628))来表达x小于628。

老四附言:

对于这一条，其实老四是有异议的，希望将来有机会和孤尽老师探讨一下。就在老四所经历的系统以及业务中，是会碰到一种情况，比如说，一个boolean flag会返回true或者false，但是只有false的时候需要我们来进行业务处理，相反true的术语系统验证通过，不需要任何处理。在这种情况下我们可能就需要这样if(!flag)这样写来做判断，而且现实开发中此情此景不在少数。

8.[推荐] 接口入参保护，这种场景常见的是用作批量操作的接口。

老四附言:

其实该条是针对接口定义而言，所谓的入参保护，老四理解为就是咱们常说的”参数校验”。一般的入参保护包括参数值的正确与否，参数值得边界等等。至于说批量操作，孤尽所言应该指的是要限制接口的批量操作的临界值。比如说下游要请求接口，一次性要将80笔订单达到你这个接口中来，那不开玩笑呢么?所以对这种数量级，一定要有所限制才行，要不然负无穷也崩溃了。再想想?这种问题卫语句是不是就能解决?

9.[参考] 下列情形，需要进行参数校验:

• 调用频次低的方法。
• 执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参数错误导致中间执行回退，或者错误，那得不偿失。
• 需要极高稳定性和可用性的方法。
• 对外提供的开放接口，不管是RPC(Remote Procedure Call，远程过程调用、远程服务调用)/API(Application Programming Interface，应用程序接口)/HTTP(HyperText Transfer Protocol，超文本传输协议)接口。
• 敏感权限入口。

老四附言:

这个没啥可分析的了，我们编程过程中尽量做到程序的稳定性。

10.[参考] 下列情形，不需要进行参数校验:

• 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。
• 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露问题。一般DAO层与Service层都在同一个应用中，部署在同一台服务器中，所以DAO的参数校验，可以省略。
• 被声明成private只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。

老四附言:

emmmmmmmmm~~~~~~~~~~~~第一条，我觉得还是该校验校验的好。

更博不易，如果觉得文章对你有帮助并且有能力的老铁烦请赞助盒烟钱，点我去赞助。或者扫描文章下面的微信/支付宝二维码打赏任意金额，老四这里抱拳了。赞助时请备注姓名或者昵称，因为您的署名会出现在赞赏列表页面，您的赞赏钱财也会被用于小站的服务器运维上面，再次抱拳。