return 对代码可读性的影响

Question

在函数中，是否应该控制尽量少的 return 出口？
比如 （以 PHP 代码举例）：

<?php

/**
 * 控制尽量少的退出点
 */
function foo1($var)
{
    try {
        if (empty($var)) {
            throw new \Exception('emty var');
        }

        if (!is_string($var)) {
            throw new \Exception('var must be string');
        }

        return sprintf("input-var:%s \n", $var);
    } catch (\Exception $e) {
        return sprintf("error:%s \n", $e->getMessage());
    }
}

/**
 * 不控制，可以结束的时候直接 return
 */
function foo2($var)
{
    if (empty($var)) {
        return 'error:empty var' . PHP_EOL;
    }

    if (!is_string($var)) {
        return 'error:var must be string' . PHP_EOL;
    }

    return sprintf("input-var:%s \n", $var);
}

常见观点

正面：应该控制

• 过多的 renturn，增加了函数出口点，不利于代码阅读

反面：没必要

• 多个 return 也没什么，类似 try-catch 在效率上有所损失，尽量少用

中立

• 两种写法只是跟人风格问题，没有优略
• 短函数多个 return 无伤大雅，但是长函数中，会严重降低可读性

---

各位客观，欢迎留下你的观点。

我的观点：
无论是短函数还是长函数，都尽量控制一下 return 点，因为短函数随着迭代可能会变成长函数。
而且多个 return 会明显降低长函数的可读性。
对于 try-catch 结构，在性能上的一丁点牺牲，换来的可读性提升，是值得的。

Answer 1

观点与你相反，函数中要尽可能多的使用 return 来控制，因为 return 从设计上来说就是这个功能，表示执行权限的移交。这样不会造成任何执行权限的问题。所谓函数，从设计之初，核心就是计算和返回。

滥用 try catch 会导致上级 try catch 无法正确捕获异常

语义化上来说，return 也比 try catch 更加清晰明了。

Answer 2

个人倾向于尽快return的原则，特别是对于多层嵌套的if和for，能第二行return，绝不放第三行。

Answer 3

请正确使用Exception机制。

Answer 4

防御式编程

<?php
function run($a) {
    if (!conditionA($a)) return false;
    if (!conditionB($a)) return false;
    //...
    return true
}

Answer 5

个人倾向return；关于可读性，return了，后面的代码就别读了。

Answer 6

其实方法单一职责后，return的使用不会那么让人讨厌

Answer 7

个人倾向尽早return，减少过多运行无用代码

Answer 8

function a($b){
    $c = '';
    if($b==1){
        $c = 1;
    }else if($b==2){
        $c = 2;
    }else{
        $c = 0;
    }
    return $c;
}

Answer 9

在我看来只要不是压缩和混淆，都不影响阅读

Answer 10

return (is_dir($this->dirPath) ? rmdir($this->dirPath) : false) ? true : false;

这种方式怎么样？

Answer 11

中立，团队自己达成一致就可以了。
运行时差异并不大。可读性是对人来说的，如果你使用IDE，比如PHPStorm来说，IDE可以很好的检测出来是否逻辑上不可达的代码或者区间空洞这种问题，如果你再使用 phpdoc 来规范你的return 类型，IDE可以直接给你标记出来你的哪些返回是有问题的。如果你使用phpcs这种静态扫描工具再结合IDE来一起工作的话，你会发现，IDE给出的提示会非常详细。。细到你不想使用。。。
如果你说的可读性是指 文本编辑器 里的可读性，你还是在团队里面规范下IDE的使用吧。

Answer 12

持相反意见，个人代码习惯倾向于尽早将不适合的结果return，最终底部的return返回正常流程的结果。

一个显著的效果是可以很大程度减少代码的嵌套层数，这比减少程序多个出口对于代码可读性的提高影响更大。

try...catch...只用在数据库事务的情况下，抛出异常并回退数据。

Answer 13

持相反意见，尽早返回不适合的结果，阅读性更好。

Answer 14

尽早返回。
造成难以阅读的不是return多，是代码有其他问题。

Answer 15

个人倾向尽早return；
函数越短越好，单一职责，划分最小单元。

Answer 16

应该尽早return，这样可以简化排错读代码时的难度，毕竟到第一行直接就return出去都下一个方法，总比读完100行代码发现只有第一行有用，要好的多

Answer 17

应该尽早 return 支持 +1，减少嵌套和圈复杂度，感觉还是挺不错的哦 (•̀ロ•́)و✧ ~~

Answer 18

支持尽早return方案，这样代码可读性较好点！