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

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

这完全是有争议的。在提前返回的问题上，“程序员之间没有达成一致”。据我所知，这总是主观的。

这是有可能的，因为最好有条件，所以它们通常是真的;也可以说，它更清晰。另一方面，它确实创建了嵌套测试。

我不认为你会对这个问题得到一个结论性的答案。

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

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

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

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

正如其他人所提到的，不应该对性能造成影响，但还有其他考虑因素。除了这些合理的担忧，在某些情况下，这也会让你陷入困境。假设你处理的是一个double:

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

将其与看似等效的反转进行对比:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

所以在某些情况下，看起来是正确的a颠倒的if可能不是。

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

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

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