我能想到的一个很好的理由是代码维护:您有一个单一的退出点。如果你想改变结果的格式，…，它的实现要简单得多。此外，为了调试，你可以在那里插入一个断点:)

话虽如此，我曾经不得不在一个库中工作，那里的编码标准强制要求“每个函数一个返回语句”，我发现这相当困难。我写了很多数值计算代码，经常有“特殊情况”，所以代码最终很难跟上……

在一个没有副作用的函数中，没有理由有多个返回值，你应该用函数式的风格来编写它们。在有副作用的方法中，事情更有顺序(时间索引)，因此您使用命令式风格编写，使用return语句作为停止执行的命令。

换句话说，如果可能的话，尽量采用这种风格

return a > 0 ?
  positively(a):
  negatively(a);

在这

if (a > 0)
  return positively(a);
else
  return negatively(a);

如果您发现自己编写了几层嵌套的条件，可能有一种方法可以重构它，例如使用谓词列表。如果您发现If和else在语法上相差很大，您可能希望将其分解为更小的函数。跨越超过一屏文本的条件块很难阅读。

没有适用于每一种语言的严格规则。像只有一个return语句这样的东西不会使你的代码好。但是好的代码将允许您以这种方式编写函数。

我经常在一个方法的开头有几个语句来返回“简单”的情况。例如，这个:

public void DoStuff(Foo foo)
{
    if (foo != null)
    {
        ...
    }
}

．.． (恕我直言)可以像这样变得更具可读性:

public void DoStuff(Foo foo)
{
    if (foo == null) return;

    ...
}

所以，是的，我认为从一个函数/方法中有多个“出口点”是很好的。

我倾向于单一退出，除非事情真的变得复杂。我发现在某些情况下，多个存在点可以掩盖其他更重要的设计问题:

public void DoStuff(Foo foo)
{
    if (foo == null) return;
}

在看到这段代码时，我马上会问:

'foo'是否为空? 如果是这样，有多少客户端'DoStuff'曾经调用一个空'foo'函数?

根据这些问题的答案，可能是这样

这种检查毫无意义，因为它从来都不是真的。它应该是一个断言) 这种检查很少是正确的，所以最好改变那些特定的调用函数，因为它们可能应该采取一些其他的操作。

在上述两种情况下，代码可能都可以用断言重做，以确保'foo'永远不为空，并更改相关的调用者。

还有另外两个原因(我认为是针对c++代码的)，多重存在实际上会产生负面影响。它们是代码大小和编译器优化。

在函数出口作用域中的非pod c++对象将调用其析构函数。如果有几个return语句，那么作用域中可能有不同的对象，因此要调用的析构函数列表也会不同。因此，编译器需要为每个return语句生成代码:

void foo (int i, int j) {
  A a;
  if (i > 0) {
     B b;
     return ;   // Call dtor for 'b' followed by 'a'
  }
  if (i == j) {
     C c;
     B b;
     return ;   // Call dtor for 'b', 'c' and then 'a'
  }
  return 'a'    // Call dtor for 'a'
}

如果代码大小是一个问题，那么这可能是值得避免的。

另一个问题涉及到“命名返回值优化”(又名复制省略，ISO c++ '03 12.8/15)。c++允许实现在可以的情况下跳过调用复制构造函数:

A foo () {
  A a1;
  // do something
  return a1;
}

void bar () {
  A a2 ( foo() );
}

就像代码一样，对象'a1'是在'foo'中构造的，然后它的复制构造将被调用来构造'a2'。然而，复制省略允许编译器在堆栈上与'a2'相同的位置构造'a1'。因此，当函数返回时，不需要“复制”对象。

多个出口点会使编译器的检测工作复杂化，至少对于相对较新的vc++版本，优化不会发生在函数体有多个返回的地方。有关详细信息，请参阅Visual c++ 2005中的命名返回值优化。

I've seen it in coding standards for C++ that were a hang-over from C, as if you don't have RAII or other automatic memory management then you have to clean up for each return, which either means cut-and-paste of the clean-up or a goto (logically the same as 'finally' in managed languages), both of which are considered bad form. If your practices are to use smart pointers and collections in C++ or another automatic memory system, then there isn't a strong reason for it, and it become all about readability, and more of a judgement call.

是否有充分的理由说明在函数中只有一个return语句是一个更好的实践?

是的，有:

The single exit point gives an excellent place to assert your post-conditions. Being able to put a debugger breakpoint on the one return at the end of the function is often useful. Fewer returns means less complexity. Linear code is generally simpler to understand. If trying to simplify a function to a single return causes complexity, then that's incentive to refactor to smaller, more general, easier-to-understand functions. If you're in a language without destructors or if you don't use RAII, then a single return reduces the number of places you have to clean up. Some languages require a single exit point (e.g., Pascal and Eiffel).

这个问题通常被提出为多个返回或深度嵌套的if语句之间的错误二分法。几乎总有第三种解决方案，它是线性的(没有深度嵌套)，只有一个出口点。

更新:MISRA的指导方针显然也提倡单次退出。

需要澄清的是，我并不是说拥有多个回报总是错误的。但如果有其他等价的解决方案，有很多很好的理由选择单一回报的方案。