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

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

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

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

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

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

这里有几个很好的观点，但如果方法非常冗长，多个返回点也可能是不可读的。也就是说，如果你打算使用多个返回点，只要确保你的方法是简短的，否则多个返回点的可读性奖励可能会丢失。

保护子句或先决条件(正如您可能看到的那样)检查是否满足某个条件，然后中断程序的流程。它们适用于只对if语句的一个结果感兴趣的地方。所以不要说:

if (something) {
    // a lot of indented code
}

反转条件，如果反转条件满足，则中断

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

返回远没有去到那么脏。它允许您传递一个值来显示函数无法运行的其余代码。

你将看到在嵌套条件下应用这个的最佳示例:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

vs:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

你会发现很少有人认为第一种说法更清晰，当然，这完全是主观的。有些程序员喜欢通过缩进来知道某些东西在什么条件下运行，而我更愿意保持方法流是线性的。

我不是说precons会改变你的生活或让你上床，但你可能会发现你的代码更容易阅读。

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

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

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

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

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