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

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

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

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

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

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

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

这是意见的问题。

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

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

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

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

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

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