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

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

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

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

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

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

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

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

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

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

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

这是意见的问题。

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

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

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

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