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

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

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

正如Kent Beck在《实现模式》中讨论保护子句时指出的那样，使一个例程具有单一的入口和出口点……

是为了防止可能的混淆 当你在许多地方跳来跳去 同一例程中的位置。这让 当应用到FORTRAN或 汇编语言程序 有大量的全球数据，甚至 理解哪些语句是 执行是一项艰苦的工作……使用小方法和大部分本地数据，它是不必要的保守。”

我发现用保护子句编写的函数要比一长串嵌套的if then else语句容易理解得多。

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

总是要求单一的返回类型是没有意义的。我认为这更像是一个标志，表明某些东西可能需要简化。有时有多个回报是必要的，但通常你可以通过至少尝试有一个退出点来简化事情。

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

如果你不使用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使得多个出口资源问题变得毫无意义。

在其他条件相同的情况下，单一出口点可以显著提高代码的可读性。 但有一个问题:流行的结构

resulttype res;
if if if...
return res;

是假的，“res=”不比“return”好多少。它只有一个return语句，但函数实际结束的地方有多个点。

如果你的函数有多个返回值(或“res=”s)，最好将它分解成几个较小的函数，每个函数都有一个退出点。