作为嵌套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);

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

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

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

在这

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

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

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

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

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

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

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

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

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

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

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