多个返回点在C中是一个问题(在较小程度上是c++)，因为它们迫使您在每个返回点之前复制清理代码。对于垃圾收集，try |最终构造并使用块，您真的没有理由害怕它们。

归根结底，这取决于你和你的同事觉得什么更容易阅读。

我的想法是“在函数中间”的返回不应该那么“主观”。 原因很简单，以下面的代码为例:

    function do_something( data ){

      if (!is_valid_data( data )) 
            return false;


       do_something_that_take_an_hour( data );

       istance = new object_with_very_painful_constructor( data );

          if ( istance is not valid ) {
               error_message( );
                return ;

          }
       connect_to_database ( );
       get_some_other_data( );
       return;
    }

也许第一个“回报”不是那么直观，但这是真正的储蓄。 有太多关于干净代码的“想法”，只是需要更多的实践来摆脱他们“主观的”坏想法。

就我个人而言，我倾向于只有一个退出点。如果您保持方法的简短和切中要害，这很容易实现，并且它为下一个处理您的代码的人提供了可预测的模式。

eg.

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

如果您只是想在函数退出之前检查函数中某些局部变量的值，这也是非常有用的。您所需要做的就是在最终返回值上放置一个断点，并保证能够命中它(除非抛出异常)。

我想这要看你喜欢什么了，如前所述，没有统一的意见。 为了减少麻烦，您可以将这种警告减少为“提示”。

这里已经有很多有见地的答案，但是，我仍然想要指向一个稍微不同的情况:而不是前置条件，它实际上应该放在函数的顶部，考虑一步一步的初始化，在那里你必须检查每一步是否成功，然后继续下一步。在这种情况下，您不能检查顶部的所有内容。

当我使用Steinberg的ASIOSDK编写ASIO主机应用程序时，我发现我的代码真的难以阅读，因为我遵循了嵌套范式。它有8层深，我看不出有什么设计缺陷，正如Andrew Bullock上面提到的那样。当然，我可以将一些内部代码打包到另一个函数中，然后在那里嵌套剩余的级别以使其更具可读性，但对我来说这似乎相当随机。

通过用保护子句替换嵌套，我甚至发现了自己的一个误解，即一部分清理代码应该在函数的早期出现，而不是在函数的末尾。对于嵌套分支，我从来没有看到过，你甚至可以说它们导致了我的误解。

所以这可能是另一种情况，反向if可以有助于更清晰的代码。

只在函数结束时返回的想法来自语言支持异常之前的时代。它使程序能够依赖于能够将清理代码放在方法的末尾，然后确保它会被调用，而其他程序员不会在方法中隐藏导致跳过清理代码的返回值。跳过清理代码可能导致内存或资源泄漏。

然而，在支持异常的语言中，它不提供这样的保证。在支持异常的语言中，任何语句或表达式的执行都可能导致导致方法结束的控制流。这意味着清理必须通过使用finally或使用关键字来完成。

不管怎样，我想说的是，我认为很多人引用了“只在方法末尾返回”的指导原则，却不理解为什么它是一件好事，而减少嵌套以提高可读性可能是一个更好的目标。