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

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

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

这是一个有点宗教的争论，但我同意ReSharper的观点，你应该更喜欢少嵌套。我相信这超过了一个函数有多条返回路径的缺点。

减少嵌套的关键原因是为了提高代码的可读性和可维护性。请记住，将来会有许多其他开发人员需要阅读您的代码，而缩进较少的代码通常更容易阅读。

前置条件是一个很好的例子，说明在函数开始时可以提前返回。为什么函数其余部分的可读性会受到前置条件检查的影响?

至于从一个方法返回多次的缺点——现在调试器非常强大，很容易找到特定函数返回的确切位置和时间。

函数中有多个返回值并不会影响维护程序员的工作。

糟糕的代码可读性会。

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

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

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

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

这里有几个很好的观点，但如果方法非常冗长，多个返回点也可能是不可读的。也就是说，如果你打算使用多个返回点，只要确保你的方法是简短的，否则多个返回点的可读性奖励可能会丢失。

这当然是主观的，但我认为它极大地改善了两点:

现在很明显，如果条件成立，函数就没有什么可做的了。 它保持嵌套级别较低。嵌套对可读性的伤害比你想象的要大。