有人可能会说……如果在执行函数的任务之前必须满足多个条件，那么在满足这些条件之前不要调用函数:

而不是:

function doStuff(foo) {
    if (foo != null) return;
}

Or

function doStuff(foo) {
    if (foo !== null) {
        ...
    }
}

在foo != null之前不要调用doStuff

if(foo != null) doStuff(foo);

这要求每个调用站点确保在调用之前满足调用的条件。如果有多个调用站点，则该逻辑最好放在单独的函数中、待调用函数的方法中(假设它们是一级公民)或代理中。

关于函数是否在数学上是可证明的这个话题，要考虑逻辑而不是语法。如果一个函数有多个返回点，这并不意味着(默认情况下)它在数学上不可证明。

我想说的是，你应该有尽可能多的需要，或者任何使代码更干净的(如保护子句)。

我个人从来没有听过/见过任何“最佳实践”说你应该只有一个返回语句。

在大多数情况下，我倾向于根据逻辑路径尽快退出函数(保护子句就是一个很好的例子)。

我强迫自己只使用一个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);
}

当然，它会更长，而且有点乱，但在以这种方式重构函数的过程中，我们已经

创建了许多可重用的函数， 使函数更具人类可读性，以及 函数的重点在于为什么值是正确的。

我认为在不同的情况下，不同的方法更好。例如，如果您应该在返回之前处理返回值，则应该有一个退出点。但在其他情况下，使用多次返回会更舒服。

一个音符。如果在某些情况下，你应该在返回之前处理返回值，但不是所有情况下，最好的解决方案(IMHO)是定义一个像ProcessVal这样的方法，并在返回之前调用它:

var retVal = new RetVal();

if(!someCondition)
    return ProcessVal(retVal);

if(!anotherCondition)
   return retVal;

使用单一的退出点有好处，就像不可避免的“箭头”编程也有坏处一样。

如果在输入验证或资源分配期间使用多个出口点，我尝试将所有“错误出口”非常明显地放在函数的顶部。

“SSDSLPedia”的Spartan Programming文章和“Portland Pattern Repository’s Wiki”的单一函数出口点文章都对此有一些深刻的争论。当然，还有这篇文章要考虑。

例如，如果您真的需要一个单一的退出点(在任何不支持异常的语言中)，以便在一个地方释放资源，我发现仔细应用goto是很好的;请看这个相当做作的例子(压缩以节省屏幕空间):

int f(int y) {
    int value = -1;
    void *data = NULL;

    if (y < 0)
        goto clean;

    if ((data = malloc(123)) == NULL)
        goto clean;

    /* More code */

    value = 1;
clean:
   free(data);
   return value;
}

就我个人而言，总的来说，我不喜欢箭头编程，而不喜欢多个出口点，尽管两者在正确应用时都很有用。当然，最好的方法是将程序的结构设计成两者都不需要。将你的函数分解成多个块通常会有所帮助:)

尽管在这样做的时候，我发现我最终得到了多个出口点，就像在这个例子中，一些较大的函数被分解成几个较小的函数:

int g(int y) {
  value = 0;

  if ((value = g0(y, value)) == -1)
    return -1;

  if ((value = g1(y, value)) == -1)
    return -1;

  return g2(y, value);
}

根据项目或编码指南的不同，大多数样板代码可以被宏替换。作为旁注，这样分解可以使函数g0、g1、g2非常容易单独测试。

显然，在面向对象和支持异常的语言中，我不会使用这样的if语句(或者根本不会使用，如果我可以用足够少的努力就能摆脱它的话)，代码将更加简单。和non-arrowy。大多数非最终回报可能是例外。

简而言之,

少回报比多回报好 多于一次的返回比巨大的箭头更好，并且保护条款通常是可以的。 在可能的情况下，例外可能/应该取代大多数“保护条款”。

我曾经使用过糟糕的编码标准，强迫你使用单一的退出路径，如果函数不是琐碎的，结果几乎总是非结构化的意大利面条——你最终会遇到许多中断和继续。