我能想到的一个很好的理由是代码维护:您有一个单一的退出点。如果你想改变结果的格式，…，它的实现要简单得多。此外，为了调试，你可以在那里插入一个断点:)

话虽如此，我曾经不得不在一个库中工作，那里的编码标准强制要求“每个函数一个返回语句”，我发现这相当困难。我写了很多数值计算代码，经常有“特殊情况”，所以代码最终很难跟上……

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

你知道有句谚语——情人眼里出西施。

有些人信得过NetBeans，有些人信得过IntelliJ IDEA，有些人信得过Python，有些人信得过PHP。

在一些商店，如果你坚持这样做，你可能会丢掉工作:

public void hello()
{
   if (....)
   {
      ....
   }
}

这个问题完全是关于可见性和可维护性。

I am addicted to using boolean algebra to reduce and simplify logic and use of state machines. However, there were past colleagues who believed my employ of "mathematical techniques" in coding is unsuitable, because it would not be visible and maintainable. And that would be a bad practice. Sorry people, the techniques I employ is very visible and maintainable to me - because when I return to the code six months later, I would understand the code clearly rather seeing a mess of proverbial spaghetti.

嘿，伙计(就像一个前客户曾经说过的)，做你想做的，只要你知道如何在我需要你解决它的时候解决它。

I remember 20 years ago, a colleague of mine was fired for employing what today would be called agile development strategy. He had a meticulous incremental plan. But his manager was yelling at him "You can't incrementally release features to users! You must stick with the waterfall." His response to the manager was that incremental development would be more precise to customer's needs. He believed in developing for the customers needs, but the manager believed in coding to "customer's requirement".

我们经常因为打破数据规范化、MVP和MVC边界而感到内疚。我们内联而不是构造函数。我们走捷径。

就我个人而言，我认为PHP是一种糟糕的实践，但我又知道什么呢?所有的理论争论都归结为试图满足一套规则

质量=精度，可维护性 和盈利能力。

所有其他规则都退居幕后。当然，这条规则永远不会消失:

懒惰是一种美德 程序员。

为了实现良好的标准和行业最佳实践，我们必须在所有函数中建立正确的返回语句数量。显然，人们一致反对使用一个return语句。所以我建议把它设为2。

如果每个人现在都能检查一下他们的代码，找到任何只有一个出口点的函数，并添加另一个出口点，我将不胜感激。在哪里不重要。

这一变化的结果无疑将是更少的bug，更大的可读性和难以想象的财富从天而降。

永远不要在方法中使用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语句。它们是最容易阅读的。

在某些情况下，这并不好。有时从函数返回可能非常复杂。我记得有一种情况，所有函数都必须链接到多个不同的库。一个库期望返回值是错误/状态代码，而其他库则不期望。使用一个return语句可以节省时间。

我很惊讶没人提到goto。Goto并不是每个人都想让你相信的编程的祸害。如果必须在每个函数中只有一个return语句，请将它放在末尾，并根据需要使用gotos跳转到该return语句。绝对避免标记和箭头编程，它们既丑陋又运行缓慢。