• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

论减少代码中return语句的骚操作

开发技术 开发技术 1周前 (10-17) 10次浏览

一.写作背景

最近组内在推行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数量的检测,哈哈。

  

 


喜欢 (0)