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

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

“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。大多数非最终回报可能是例外。

简而言之,

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

我倾向于认为函数中间的return语句是不好的。您可以使用返回在函数的顶部构建一些保护子句，当然也可以告诉编译器在函数的末尾返回什么，但函数中间的返回很容易被忽略，并且会使函数更难解释。

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

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

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

我通常的策略是在函数的末尾只有一个return语句，除非通过添加更多的return语句来大大降低代码的复杂性。事实上，我是Eiffel的粉丝，它通过没有return语句强制执行唯一的返回规则(只有一个自动创建的'result'变量来放入结果)。

当然，在某些情况下，有多个返回值的代码比没有返回值的代码更清晰。有人可能会说，如果一个函数太复杂，没有多个return语句就无法理解，那么就需要更多的返工，但有时对这种事情采取务实的态度是好的。

函数中return语句越多，该方法的复杂性就越高。如果您发现自己想知道是否有太多的return语句，那么您可能需要问问自己，该函数中是否有太多的代码行。

但是，不是，一个/多个返回语句并没有错。在某些语言中，这是一种比其他语言(C)更好的实践(c++)。

使用单个出口点确实在调试中提供了优势，因为它允许您在函数的末尾设置单个断点，以查看实际将返回的值。