I always avoid multiple return statements. Even in small functions. Small functions can become larger, and tracking the multiple return paths makes it harder (to my small mind) to keep track of what is going on. A single return also makes debugging easier. I've seen people post that the only alternative to multiple return statements is a messy arrow of nested IF statements 10 levels deep. While I certain agree that such coding does occur, it isn't the only option. I wouldn't make the choice between a multiple return statements and a nest of IFs, I'd refactor it so you'd eliminate both. And that is how I code. The following code eliminates both issues and, in my mind, is very easy to read:

public string GetResult()
{
    string rv = null;
    bool okay = false;

    okay = PerformTest(1);

    if (okay)
    {
        okay = PerformTest(2);
    }

    if (okay)
    {
        okay = PerformTest(3);
    }

    if (okay)
    {
        okay = PerformTest(4);
    };

    if (okay)
    {
        okay = PerformTest(5);
    }

    if (okay)
    {
        rv = "All Tests Passed";
    }

    return rv;
}

作为嵌套if的替代方法，有一种使用do/while(false)在任何地方爆发的方法:

    function()
    {
        HRESULT error = S_OK;

        do
        {
            if(!SUCCEEDED(Operation1()))
            {
                error = OPERATION1FAILED;
                break;
            }

            if(!SUCCEEDED(Operation2()))
            {
                error = OPERATION2FAILED;
                break;
            }

            if(!SUCCEEDED(Operation3()))
            {
                error = OPERATION3FAILED;
                break;
            }
            if(!SUCCEEDED(Operation4()))
            {
                error = OPERATION4FAILED;
                break;
            }
        } while (false);

        return error;
    }

这为您提供了一个出口点，允许您进行其他嵌套操作，但仍然不是真正的深层结构。如果你不喜欢成功，你可以做任何失败的事情。这类事情还允许您在任意两个其他检查之间添加其他代码，而无需重新缩进任何内容。

如果你真的疯了，整个If块也可以宏化。: D

    #define BREAKIFFAILED(x,y) if (!SUCCEEDED((x))) { error = (Y); break; }

    do
    {
        BREAKIFFAILED(Operation1(), OPERATION1FAILED)
        BREAKIFFAILED(Operation2(), OPERATION2FAILED)
        BREAKIFFAILED(Operation3(), OPERATION3FAILED)
        BREAKIFFAILED(Operation4(), OPERATION4FAILED)
    } while (false);

我认为在不同的情况下，不同的方法更好。例如，如果您应该在返回之前处理返回值，则应该有一个退出点。但在其他情况下，使用多次返回会更舒服。

一个音符。如果在某些情况下，你应该在返回之前处理返回值，但不是所有情况下，最好的解决方案(IMHO)是定义一个像ProcessVal这样的方法，并在返回之前调用它:

var retVal = new RetVal();

if(!someCondition)
    return ProcessVal(retVal);

if(!anotherCondition)
   return retVal;

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

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

Well, maybe I'm one of the few people here old enough to remember one of the big reasons why "only one return statement" was pushed so hard. It's so the compiler can emit more efficient code. For each function call, the compiler typically pushes some registers on the stack to preserve their values. This way, the function can use those registers for temporary storage. When the function returns, those saved registers have to be popped off the stack and back into the registers. That's one POP (or MOV -(SP),Rn) instruction per register. If you have a bunch of return statements, then either each one has to pop all the registers (which makes the compiled code bigger) or the compiler has to keep track of which registers might have been modified and only pop those (decreasing code size, but increasing compilation time).

今天仍然坚持使用一个return语句的一个原因是易于自动重构。如果您的IDE支持方法提取重构(选择一系列行并将它们转换为一个方法)，那么如果您想提取的行中有一个return语句，特别是如果您正在返回一个值，则很难做到这一点。

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

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

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

简而言之,

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