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

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

我强迫自己只使用一个return语句，因为在某种意义上它会产生代码气味。让我解释一下:

function isCorrect($param1, $param2, $param3) {
    $toret = false;
    if ($param1 != $param2) {
        if ($param1 == ($param3 * 2)) {
            if ($param2 == ($param3 / 3)) {
                $toret = true;
            } else {
                $error = 'Error 3';
            }
        } else {
            $error = 'Error 2';
        }
    } else {
        $error = 'Error 1';
    }
    return $toret;
}

(条件是任意的…)

条件越多，函数越大，读取起来就越困难。因此，如果您熟悉代码气味，您就会意识到它，并想要重构代码。两种可能的解决方案是:

多的回报 重构为单独的函数

多的回报

function isCorrect($param1, $param2, $param3) {
    if ($param1 == $param2)       { $error = 'Error 1'; return false; }
    if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
    if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
    return true;
}

单独的功能

function isEqual($param1, $param2) {
    return $param1 == $param2;
}

function isDouble($param1, $param2) {
    return $param1 == ($param2 * 2);
}

function isThird($param1, $param2) {
    return $param1 == ($param2 / 3);
}

function isCorrect($param1, $param2, $param3) {
    return !isEqual($param1, $param2)
        && isDouble($param1, $param3)
        && isThird($param2, $param3);
}

当然，它会更长，而且有点乱，但在以这种方式重构函数的过程中，我们已经

创建了许多可重用的函数， 使函数更具人类可读性，以及 函数的重点在于为什么值是正确的。

对于足够小的函数来说，多个出口点很好——也就是说，可以在一个屏幕长度上完整地查看函数。如果一个冗长的函数同样包含多个出口点，则表明该函数可以进一步分割。

也就是说，除非绝对必要，否则我避免使用多出口功能。在更复杂的函数中，由于一些模糊的行中出现的一些错误返回，我感到了错误的痛苦。

使用单个出口点确实在调试中提供了优势，因为它允许您在函数的末尾设置单个断点，以查看实际将返回的值。

Structured programming says you should only ever have one return statement per function. This is to limit the complexity. Many people such as Martin Fowler argue that it is simpler to write functions with multiple return statements. He presents this argument in the classic refactoring book he wrote. This works well if you follow his other advice and write small functions. I agree with this point of view and only strict structured programming purists adhere to single return statements per function.

我更喜欢一个return语句。一个尚未指出的原因是，一些重构工具在单点退出时工作得更好，例如Eclipse JDT提取/内联方法。