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

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

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

这是意见的问题。

我通常的方法是避免单行if，并在方法中间返回。

你不希望在你的方法中到处都是这样的行，但是在你的方法顶部检查一堆假设是有意义的，只有在它们都通过时才做实际的工作。

表演分为两部分。在软件处于生产状态时，您需要性能，但在开发和调试时也需要性能。开发人员最不想做的事情就是“等待”一些微不足道的事情。最后，在启用优化的情况下编译该代码将生成类似的代码。所以知道这些在两种情况下都有好处的小技巧是很好的。

问题中的情况很清楚，ReSharper是正确的。不是嵌套if语句，也不是在代码中创建新的作用域，而是在方法的开头设置一个明确的规则。它增加了可读性，更容易维护，并减少了人们必须筛选的规则数量。

它不仅美观，而且还减少了方法内部的最大嵌套级别。这通常被认为是一个优点，因为它使方法更容易理解(事实上，许多静态分析工具提供了一种度量方法，作为代码质量的指标之一)。

另一方面，它还使您的方法具有多个退出点，另一组人认为这是不可取的。

就我个人而言，我同意ReSharper和第一组(在有例外的语言中，我发现讨论“多个退出点”是愚蠢的;几乎任何东西都可能抛出，所以在所有方法中都有许多潜在的退出点)。

关于性能:每种语言的两个版本都应该是等效的(如果不是在IL级别，那么肯定是在代码抖动结束后)。从理论上讲，这取决于编译器，但实际上，今天任何广泛使用的编译器都能够处理比这更高级的代码优化情况。

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

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

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

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

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

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

糟糕的代码可读性会。