它不仅影响美观，而且还阻止了代码嵌套。

它实际上也可以作为确保数据有效的前提条件。

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

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

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

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

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

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

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

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

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

There are several advantages to this sort of coding but for me the big win is, if you can return quick you can improve the speed of your application. IE I know that because of Precondition X that I can return quickly with an error. This gets rid of the error cases first and reduces the complexity of your code. In a lot of cases because the cpu pipeline can be now be cleaner it can stop pipeline crashes or switches. Secondly if you are in a loop, breaking or returning out quickly can save you a lots of cpu. Some programmers use loop invariants to do this sort of quick exit but in this you can broke your cpu pipeline and even create memory seek problem and mean the the cpu needs to load from outside cache. But basically I think you should do what you intended, that is end the loop or function not create a complex code path just to implement some abstract notion of correct code. If the only tool you have is a hammer then everything looks like a nail.

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

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