这可能是一个不寻常的观点，但我认为任何相信多个return语句是有利的人都从未在只支持4个硬件断点的微处理器上使用过调试器。:-)

虽然“箭头代码”的问题是完全正确的，但当使用多个return语句时，一个问题似乎消失了，那就是在使用调试器的情况下。您没有一个方便的万能位置来放置断点，以保证您将看到退出，从而看到返回条件。

我经常在一个方法的开头有几个语句来返回“简单”的情况。例如，这个:

public void DoStuff(Foo foo)
{
    if (foo != null)
    {
        ...
    }
}

．.． (恕我直言)可以像这样变得更具可读性:

public void DoStuff(Foo foo)
{
    if (foo == null) return;

    ...
}

所以，是的，我认为从一个函数/方法中有多个“出口点”是很好的。

永远不要在方法中使用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语句。

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

这主要是Fortran的遗留问题，在Fortran中，可以将多个语句标签传递给一个函数，这样函数就可以返回其中任何一个。

所以这种代码是完全有效的

       CALL SOMESUB(ARG1, 101, 102, 103)
C Some code
 101   CONTINUE
C Some more code
 102   CONTINUE
C Yet more code
 103   CONTINUE
C You get the general idea

但是被调用的函数决定了你的代码路径。有效率呢?可能。可维护的?不。

这就是该规则的来源(顺便说一下，一个函数没有多个入口点，这在fortran和汇编程序中是可能的，但在C中不可能)。

然而，它的措辞看起来像是可以应用到其他语言(关于多个入口点的那个不能应用到其他语言，所以它不是一个真正的程序)。所以这条规则被保留了下来，即使它指的是一个完全不同的问题，而且不适用。

对于更结构化的语言，需要放弃这个规则，或者至少考虑更多。当然，一个充满返回值的函数很难理解，但在开始时返回不是问题。在一些c++编译器中，如果你只从一个地方返回一个值，那么一个返回点可能会生成更好的代码。

但是最初的规则被误解了，被误用了。也不再相关了。

我可能会因此被讨厌，但理想情况下，我认为根本不应该有return语句，函数应该只返回它最后一个表达式，在完全理想的情况下，应该只包含一个。

所以不

function name(arg) {
    if (arg.failure?)
        return;

    //code for non failure
}

而是

function name(arg) {
    if (arg.failure?)
        voidConstant
    else {
        //code for non failure


}

不是表达式的if语句和return语句对我来说是一种非常可疑的实践。

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