是否有充分的理由说明在函数中只有一个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的指导方针显然也提倡单次退出。

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

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

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

我目前正在开发一个代码库，其中有两个人盲目地赞同“单点退出”理论，我可以告诉你，从经验来看，这是一个非常可怕的实践。这使得代码极其难以维护，我将向您展示原因。

根据“单点退出”理论，你不可避免地会得到这样的代码:

function()
{
    HRESULT error = S_OK;

    if(SUCCEEDED(Operation1()))
    {
        if(SUCCEEDED(Operation2()))
        {
            if(SUCCEEDED(Operation3()))
            {
                if(SUCCEEDED(Operation4()))
                {
                }
                else
                {
                    error = OPERATION4FAILED;
                }
            }
            else
            {
                error = OPERATION3FAILED;
            }
        }
        else
        {
            error = OPERATION2FAILED;
        }
    }
    else
    {
        error = OPERATION1FAILED;
    }

    return error;
}

这不仅使代码难以理解，而且以后还需要返回并在1和2之间添加一个操作。您必须缩进整个该死的函数，并确保所有if/else条件和大括号都正确匹配。

这种方法使代码维护极其困难，而且容易出错。

拥有多个出口点本质上与使用GOTO是一样的。这是不是件坏事取决于你对迅猛龙的看法。

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

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中的命名返回值优化。

使用单一出口点可以降低圈复杂度，因此，从理论上讲，可以降低在修改代码时引入错误的可能性。然而，实践往往表明需要更务实的方法。因此，我倾向于只有一个出口点，但如果可读性更好，允许我的代码有多个出口点。