论减少代码中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数量的检测，哈哈。