[股票配资恒信宝]薛之谦唐禹哲激吻论减少代码中return语句的骚操作

最近组内在推行checkstyle代码规范的检测,关于checkstyle的介绍可以参考:https://checkstyle.sourceforge.io,〔 走势图鑫东财配资〕,

在按照checkstyle修改问题时,遇到几个很头疼的问题,最头疼就是checkstyle对function中return数量的限制,这里有两种限制:

  1.对于void返回值的function,return数量最多只允许有1个;

  2.对于非void返回值的function,return数量最多只允许个有3个;

根据上面这两个限制,在修改代码的过程中,真的是很难受,按照这个规则来写代码,会让代码变得更难理解(和人的思维方式有区别),所以我下面会简单介绍一下为啥会很头疼,然后介绍相关的骚操作,用来减少return的数量。

原文地址:https://www.cnblogs.com/-beyond/p/13831474.html

二.多个return的实例

通常项目中很多的service中都会进行组装流程,一个function中会包含多个步骤,每个步骤都会有阶段性的处理结果,并且需要根据阶段性的结果进行判断是否需要继续执行;如果不继续执行,那么就需要返回对应的错误码给上层。

比如下面这样例子

package cn.ganlixin; /** * @author ganlixin * @create 2020-10-17 */ public class CookService { private WaterManager waterManager; private VegetableManager vegetableManager; private FireManager fireManager; private RiceManager riceManager; public Result cook(Param param) { log.info("start cook check, param:{}", param); Result fireResult = fireManager.getFire(param); if (fireResult != Result.SUCCESS) { log.error("cook failed, no fire, because {}", fireResult); return fireResult; } Result waterResult = waterManager.getWater(param); if (waterResult != Result.SUCCESS) { log.error("cook failed, no water, because {}", waterResult); return waterResult; } Result riceResult = riceManager.getRice(param); if (riceResult != Result.SUCCESS) { log.error("cook failed, no rice, because {}", riceResult); return riceResult; } Result vegetableResult = vegetableManager.getVegetables(param); if (vegetableResult != Result.SUCCESS) { log.error("cook failed, no vegetables, because {}", vegetableResult); return vegetableResult; } log.info("steps checked pass success, start to do cook"); return doCook(param); } }

上面的例子中,return的数量已经由5个了,其实这个还不算多,有的大流程包含10多个return,修改这样的代码,就挺烦的。

对于上面这个代码块,说一下我的思路:

  1.上面的代码,每一步操作结果进行判断,如果不符合要求,及时终止流程,符合正常的思维;

  2.也是有可以优化的地方:return数量过多,在一定的程度上,可以认为是封装做得不好,或者说没有按照步骤的相关性单拎出来封装;比如说上面的代码中,可以将获取水、米、蔬菜的三个步骤提出来,封装一个获取食材的方法,在提出来的方法中再进行判断,这样return的数量减少了一些,同时代码也更加好理解。

三.常见的return优化方式

  下面介绍几种修改代码的方式,这些方式在初期接入checkstyle的时候,我就是按照这种方式来修改的,但是我并不推荐使用

3.1 合理使用三元表达式

修改前的代码

public Result case1(Param param) { Integer code= doSomeAction(param); if (code == 0) { return Result.SUCCESS; } else { return Result.FAIL; } }

  使用三元表达式来修改,看起来更加清爽了,如下:

public Result case1(Param param) { Integer code = doSomeAction(param); return code == 0 ? Result.SUCCESS : Result.FAIL; }

  

3.2 合并相关操作

就像前面说的,将获取水、米、蔬菜的三个步骤封装为一个大的步骤(获取食材);

除此之外,下面还有一个例子,case2接收入参后进行了两次参数合法性检测,其实这两次合法性检测是可以合并的:

public Result case2(Param param) { log.info("input param:{}", param); if (param == null) { log.info("param error"); return Result.PARAM_ERROR; } if (!checkParamValid(param)) { log.info("param error"); return Result.PARAM_ERROR; } Integer code = doSomeAction(param); return code == 0 ? Result.SUCCESS : Result.FAIL; }

  将两次检测合并,修改后的代码

public Result case2(Param param) { log.info("input param:{}", param); if (param == null || !checkParamValid(param)) { log.info("param error"); return Result.PARAM_ERROR; } Integer code = doSomeAction(param); return code == 0 ? Result.SUCCESS : Result.FAIL; }

  点评:

  1.将相关的操作进行封装、合并,不仅会让代码更简洁,阅读代码也会更好理解;

  2.上面虽然将检测操作进行了简单的合并,但是也存在一些问题,如果检测参数的时候,需要返回那个字段或者属性不合法,那么上面的方式也就不推荐了。

3.3 使用变量保存if.else.的返回值

直接看下面的代码:

public Result case3(Param param) { log.info("input param:{}", param); // 省略参数校验 if (param.role == "admin") { // ... return adminHandle(param); } else { // .. return userHandle(param); } }

  使用变量保存分支的处理结果,然后统一返回

public Result case3(Param param) { log.info("input param:{}", param); // 省略参数校验 Result res = Result.FAIL; if (param.role == "admin") { // ... res = adminHandle(param); } else { // .. res = userHandle(param); } return res; }

  点评:

  其实这种方式并不推荐,如果分支较少,并且每个分支的操作只有几行代码,这样修改也没啥关系;

  但是如果分支很多,并且每个分支的代码量很大,那么不论是写代码或者看代码,亦或者是后面维护代码,都需要小心res变量被修改错了或者忘记修改。(题外话:如果分支代码量太大,可以将分支中的操作封装一下)。

  

3.4 利用if的逆向逻辑

看一下下面代码:

public Result case4(Param param) { log.info("input param:{}", param); if (!checkParam()) { log.info("参数错误"); return Result.PARAM_ERROR; } if (!checkPermission(param.getUserId)) { log.info("没有权限"); return Result.PERMISSION_DENY; } return doAction(param); }

  要想减少上面代码return,的确是有方法,修改之后如下:

public Result case4(Param param) { log.info("input param:{}", param); Result result = Result.FAIL; if (checkParam()) { if (checkPermission(param.getUserId)) { return doAction(param); } log.info("没有权限"); Result.PERMISSION_DENY; } else { log.info("参数错误"); result = Result.PARAM_ERROR; } return result; }

  点评:

  上面这种写法,有的人看着感觉没啥,有的人看着就挺别扭。

  按照修改之前的写法,当发现参数错误是,立马返回结果,也就浏览4行代码;如果按照修改之后的代码,校验参数错误到返回结果,需要看15行左右(这只是一个简单地示例,正常业务流程中包含的代码会更多)。

四.总结

这篇博客,不是真的想举例子讲怎么去减少return数量,我觉得return数量多点也没关系,及时return也就及时结束,比较符合人的思维方式。

虽然可以使用各种骚操作去减少return的数量,比如使用if..else..去搞也是可以的,但是这样的话,一方面,从阅读代码的角度,流程更复杂了;另一方面,使用if..else去搞多层嵌套,每行的代码长度就会很多,阅读代码也不方便。

写这篇博客,笼统点说就是:

  1.做事情要多总结,映射到代码上就是多提炼、多抽象、多封装;

  2.不要为了规范而放弃一下东西,映射到代码上,就是代码可读性、代码简洁性很重要;

如果通不过规范,那么可以找上级多沟通沟通,如果理由正当且合理,那么规范也是可以跳过的,比如使用@SuppressWarnings("ReturnCount")来忽略return数量的检测,哈哈。