有人可能会说……如果在执行函数的任务之前必须满足多个条件，那么在满足这些条件之前不要调用函数:

而不是:

function doStuff(foo) {
    if (foo != null) return;
}

Or

function doStuff(foo) {
    if (foo !== null) {
        ...
    }
}

在foo != null之前不要调用doStuff

if(foo != null) doStuff(foo);

这要求每个调用站点确保在调用之前满足调用的条件。如果有多个调用站点，则该逻辑最好放在单独的函数中、待调用函数的方法中(假设它们是一级公民)或代理中。

关于函数是否在数学上是可证明的这个话题，要考虑逻辑而不是语法。如果一个函数有多个返回点，这并不意味着(默认情况下)它在数学上不可证明。

永远不要在方法中使用return语句。

我知道我会因此受到指责，但我是认真的。

返回语句基本上是过程式编程时代遗留下来的。它们是goto的一种形式，以及break、continue、if、switch/case、while、for、yield和其他一些语句以及大多数现代编程语言中的等价语句。

返回语句有效地“GOTO”函数被调用的点，并在该范围内分配一个变量。

返回语句就是我所说的“方便的噩梦”。它们似乎能快速完成任务，但却会导致大量的维护问题。

Return语句与封装语句截然相反

这是面向对象编程中最重要和最基本的概念。这是面向对象的存在理由。

当你从一个方法返回任何东西时，你基本上是在从对象中“泄露”状态信息。不管你的状态是否改变了，也不管这个信息是否来自其他对象——对调用者来说没有区别。这样做的目的是允许对象的行为在对象分解封装之外。它允许调用者开始以导致脆弱设计的方式操纵对象。

LoD是你的朋友

我建议任何开发人员在c2.com或维基百科上阅读有关得墨忒耳定律(LoD)的内容。LoD是一种设计理念，在字面意义上被用于真正的“关键任务”软件约束的地方，比如喷气推进实验室。它已被证明可以减少代码中的错误数量并提高灵活性。

关于遛狗有一个很好的类比。当你遛狗的时候，你不需要身体上抓住它的腿并移动它们，这样狗就会走。你命令狗走路，它会照顾好自己的腿。在这个类比中，return语句相当于狗让你抓住它的腿。

只和你最亲近的朋友聊天:

你所在函数的参数， 你自己的属性， 在函数中创建的任何对象

您将注意到，这些都不需要return语句。您可能认为构造函数是一个返回函数，这样您就得到了一些东西。实际上返回的是内存分配器。构造函数只是设置内存中的内容。只要新对象的封装是OK的，这就没问题，因为，当你创建它时，你对它有完全的控制权——没有人可以破坏它。

Accessing attributes of other objects is right out. Getters are out (but you knew they were bad already, right?). Setters are OK, but it is better to use constructors. Inheritance is bad - when you inherit from another class, any changes in that class can and probably will break you. Type sniffing is bad (Yes - LoD implies that Java/C++ style type based dispatch is incorrect - asking about type, even implicitly, is breaking encapsulation. Type is an implicit attribute of an object. Interfaces are The Right Thing).

So why is this all a problem? Well, unless your universe is very different from mine, you spend a lot of time debugging code. You aren't writing code that you plan never to reuse. Your software requirements are changing, and that causes internal API/interface changes. Every time you have used a return statement you have introduced a very tricky dependency - methods returning anything are required to know about how whatever they return is going to be used - that is each and every case! As soon as the interface changes, on one end or the other, everything can break, and you are faced with a lengthy and tedious bug hunt.

它们实际上是代码中的恶性肿瘤，因为一旦您开始使用它们，它们就会促进在其他地方进一步使用(这就是为什么您经常可以在对象系统中找到返回的方法链)。

那么另一种选择是什么?

告诉，不要问。

使用OOP——目标是告诉其他对象要做什么，并让它们来处理。所以你必须忘记做事的程序方法。其实很简单——只要不写return语句。做同样的事情有更好的方法:

return概念没有错，但是return语句有很大的缺陷。

如果你真的需要回复，那就回电话。甚至可以传入要填写的数据结构。通过这种方式，您可以保持接口的干净和开放，并且您的整个系统不那么脆弱，适应性更强。它不会减慢你的系统速度，事实上它可以加快系统速度，就像尾部调用优化一样——除了在这种情况下，没有尾部调用，所以你甚至不必浪费时间用返回值来操作堆栈。

如果遵循这些参数，就会发现实际上根本不需要return语句。

如果您遵循这些实践，我保证您很快就会发现您花在寻找错误上的时间要少得多，适应需求变化的速度要快得多，理解您自己的代码时遇到的问题也要少得多。

在其他条件相同的情况下，单一出口点可以显著提高代码的可读性。 但有一个问题:流行的结构

resulttype res;
if if if...
return res;

是假的，“res=”不比“return”好多少。它只有一个return语句，但函数实际结束的地方有多个点。

如果你的函数有多个返回值(或“res=”s)，最好将它分解成几个较小的函数，每个函数都有一个退出点。

我倾向于认为函数中间的return语句是不好的。您可以使用返回在函数的顶部构建一些保护子句，当然也可以告诉编译器在函数的末尾返回什么，但函数中间的返回很容易被忽略，并且会使函数更难解释。

唯一重要的问题是“如何使代码更简单、更易读、更容易理解?”如果使用多个返回会更简单，那么就使用它们。

是否有充分的理由说明在函数中只有一个return语句是一个更好的实践?

是的，有:

The single exit point gives an excellent place to assert your post-conditions. Being able to put a debugger breakpoint on the one return at the end of the function is often useful. Fewer returns means less complexity. Linear code is generally simpler to understand. If trying to simplify a function to a single return causes complexity, then that's incentive to refactor to smaller, more general, easier-to-understand functions. If you're in a language without destructors or if you don't use RAII, then a single return reduces the number of places you have to clean up. Some languages require a single exit point (e.g., Pascal and Eiffel).

这个问题通常被提出为多个返回或深度嵌套的if语句之间的错误二分法。几乎总有第三种解决方案，它是线性的(没有深度嵌套)，只有一个出口点。

更新:MISRA的指导方针显然也提倡单次退出。

需要澄清的是，我并不是说拥有多个回报总是错误的。但如果有其他等价的解决方案，有很多很好的理由选择单一回报的方案。