一个函数应该只有一个return语句吗？

已锁定 。 该问题及其答案被锁定，由于该问题是题外话，但具备历史意义。 它目前不接受新的答案或互动。 了解更多 。

是否有充分的理由说明为何在函数中仅包含一个return语句是一种更好的作法？

仍是在逻辑上正确地从函数中返回就能够，这意味着函数中可能有不少return语句？

---

#1楼

这多是一个不一样寻常的观点，可是我认为，任何认为支持多个return语句的人都没必要在仅支持4个硬件断点的微处理器上使用调试器。 ;-)

尽管“箭头代码”问题是彻底正确的，可是在使用多个return语句时彷佛已经消失的一个问题是使用调试器的状况。 您没有方便的万能位置放置断点以确保您将看到出口以及返回条件。

---

#2楼

我强迫本身只使用一个return语句，由于它在某种意义上会产生代码气味。 让我解释：

function isCorrect($param1, $param2, $param3) {
    $toret = false;
    if ($param1 != $param2) {
        if ($param1 == ($param3 * 2)) {
            if ($param2 == ($param3 / 3)) {
                $toret = true;
            } else {
                $error = 'Error 3';
            }
        } else {
            $error = 'Error 2';
        }
    } else {
        $error = 'Error 1';
    }
    return $toret;
}

（条件是精明的...）

条件越多，功能越大，则读取起来就越困难。 所以，若是您习惯了代码的味道，您就会意识到它，并但愿重构代码。 两种可能的解决方案是：

• 屡次退货
• 重构为单独的功能

屡次退货

function isCorrect($param1, $param2, $param3) {
    if ($param1 == $param2)       { $error = 'Error 1'; return false; }
    if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
    if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
    return true;
}

分开的功能

function isEqual($param1, $param2) {
    return $param1 == $param2;
}

function isDouble($param1, $param2) {
    return $param1 == ($param2 * 2);
}

function isThird($param1, $param2) {
    return $param1 == ($param2 / 3);
}

function isCorrect($param1, $param2, $param3) {
    return !isEqual($param1, $param2)
        && isDouble($param1, $param3)
        && isThird($param2, $param3);
}

固然，它更长而且有点混乱，可是在以这种方式重构函数的过程当中，咱们已经

• 建立了许多可重用的功能，
• 使该功能更易于阅读，而且
• 函数的重点在于为何值正确。

---

#3楼

我相信屡次返回一般是好的（在我用C＃编写的代码中）。 单返回样式是C的保留。可是您可能没有使用C进行编码。

在全部编程语言中，没有法律只要求一个方法的一个退出点 。 有些人坚持这种风格的优越性，有时他们将其提高为“规则”或“法律”，但这种信念没有任何证据或研究的支持。

不止一种返回样式在C代码中多是一个坏习惯，在C代码中必须显式地取消分配资源，可是Java，C＃，Python或JavaScript之类的语言具备自动垃圾回收和try..finally块等try..finally （并using C＃中的代码块），而且该参数不适用-在这些语言中，须要集中手动分配资源很是罕见。

在某些状况下，单项退货更具可读性，而在某些状况下则否则。 看看它是否减小了代码行数，使逻辑更清晰或减小了花括号，缩进或临时变量的数量。

所以，请使用尽量多的适合您的艺术敏感性的退货，由于这是一种布局和可读性问题，而不是技术性问题。

我已经在博客上更详细地讨论了这一点 。

---

#4楼

不，由于咱们再也不生活在1970年代 。 若是您的函数足够长而致使屡次返回是一个问题，那就太长了。

（除了如下事实外，语言中的任何多行函数（除例外状况外）都将具备多个出口点。）

---

#5楼

你知道格言- 情人在旁观者眼中 。

有些人对NetBeans发誓，有些人对IntelliJ IDEA发誓，有些人对Python发誓，而有些人对PHP发誓。

若是坚持这样作，在某些商店中，您可能会失业：

public void hello()
{
   if (....)
   {
      ....
   }
}

问题全在于可见性和可维护性。

我沉迷于使用布尔代数来简化和简化逻辑以及使用状态机。 可是，有些同事认为我在编码中使用“数学技术”是不合适的，由于它不可见且不可维护。 那将是一个坏习惯。 抱歉，我使用的技术对我来讲是很是明显和可维护的-由于六个月后我回到代码时，我会清楚地理解代码，而不会看到一团混乱的意大利面条。

嘿哥们（就像之前的客户曾经说过的）会作您想作的事情，只要您知道如何修复它，当我须要您修复它时便可。

我记得20年前，个人一位同事因采用今天称为敏捷开发策略的工做而被解雇。 他有一个细致的增量计划。 可是他的经理对他大吼：“您不能向用户逐步发布功能！您必须坚持瀑布式设计 。” 他对经理的回应是，渐进式开发将更精确地知足客户的需求。 他相信要开发知足客户需求的产品，但经理相信要按照“客户要求”进行编码。

咱们常常因违反数据规范化， MVP和MVC界限而感到内gui。 咱们内联而不是构造一个函数。 咱们采起捷径。

我我的认为PHP是很差的作法，可是我知道什么。 全部理论上的争论归结为试图知足一套规则

质量=精度，可维护性和盈利能力。

全部其余规则逐渐淡出背景。 固然，这条规则永远不会消失：

懒惰是优秀程序员的美德。