有时出于性能考虑，这是必要的(我不想获取不同的缓存线，就像继续一样;有时)。

如果你不使用RAII分配资源(内存、文件描述符、锁等)，那么多次返回很容易出错，而且肯定是重复的，因为释放需要手动执行多次，你必须仔细跟踪。

在这个例子中:

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;
}

我会把它写成:

function() {
    HRESULT error = OPERATION1FAILED;//assume failure
    if(SUCCEEDED(Operation1())) {

        error = OPERATION2FAILED;//assume failure
        if(SUCCEEDED(Operation3())) {

            error = OPERATION3FAILED;//assume failure
            if(SUCCEEDED(Operation3())) {

                error = OPERATION4FAILED; //assume failure
                if(SUCCEEDED(Operation4())) {

                    error = S_OK;
                }
            }
        }
    }
    return error;
}

这当然看起来更好。

这在手动资源释放的情况下尤其有用，因为在哪里和哪些释放是必要的是相当直接的。如下例所示:

function() {
    HRESULT error = OPERATION1FAILED;//assume failure
    if(SUCCEEDED(Operation1())) {

        //allocate resource for op2;
        char* const p2 = new char[1024];
        error = OPERATION2FAILED;//assume failure
        if(SUCCEEDED(Operation2(p2))) {

            //allocate resource for op3;
            char* const p3 = new char[1024];
            error = OPERATION3FAILED;//assume failure
            if(SUCCEEDED(Operation3(p3))) {

                error = OPERATION4FAILED; //assume failure
                if(SUCCEEDED(Operation4(p2,p3))) {

                    error = S_OK;
                }
            }
            //free resource for op3;
            delete [] p3;
        }
        //free resource for op2;
        delete [] p2;
    }
    return error;
}

如果在没有RAII(忘记异常问题!)的情况下使用多个出口编写这段代码，则必须多次写入删除。如果你用}else{then 这有点难看。

但是RAII使得多个出口资源问题变得毫无意义。

如果可以只写下一个观点，那就是我的观点:

我完全不同意“单返回语句理论”，认为它在代码可读性、逻辑和描述方面都是推测性的，甚至是破坏性的。

使用一次-一次返回的习惯对于纯过程式编程来说都很糟糕，更不用说更高级的抽象(函数式、组合式等)了。此外，我希望所有以这种风格编写的代码都经过一些特殊的重写解析器，使其具有多个返回语句!

一个函数(如果它真的是一个函数/查询，根据“查询-命令分离”注意-见埃菲尔编程语言。例如)必须定义与控制流场景一样多的返回点。它在数学上更加清晰和一致;它是编写函数(即查询)的方法。

但对于你的特工收到的突变信息——程序调用，我不会那么激进。

由于错误处理，您已经隐式地拥有多个隐式返回语句，因此要处理它。

但是，就像编程中的典型情况一样，有支持和反对多次返回实践的例子。如果它能让代码更清晰，那就这样做。使用许多控制结构会有所帮助(例如case语句)。

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

而不是:

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

Or

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

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

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

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

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

如果你最终得到了很多返回值，那么你的代码可能有问题。否则，我同意有时能够从子例程的多个位置返回是很好的，特别是当它使代码更干净的时候。

Perl 6:坏例子

sub Int_to_String( Int i ){
  given( i ){
    when 0 { return "zero" }
    when 1 { return "one" }
    when 2 { return "two" }
    when 3 { return "three" }
    when 4 { return "four" }
    ...
    default { return undef }
  }
}

这样写会更好吗

Perl 6:好例子

@Int_to_String = qw{
  zero
  one
  two
  three
  four
  ...
}
sub Int_to_String( Int i ){
  return undef if i < 0;
  return undef unless i < @Int_to_String.length;
  return @Int_to_String[i]
}

注意，这只是一个简单的例子

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