使用单一的退出点有好处，就像不可避免的“箭头”编程也有坏处一样。

如果在输入验证或资源分配期间使用多个出口点，我尝试将所有“错误出口”非常明显地放在函数的顶部。

“SSDSLPedia”的Spartan Programming文章和“Portland Pattern Repository’s Wiki”的单一函数出口点文章都对此有一些深刻的争论。当然，还有这篇文章要考虑。

例如，如果您真的需要一个单一的退出点(在任何不支持异常的语言中)，以便在一个地方释放资源，我发现仔细应用goto是很好的;请看这个相当做作的例子(压缩以节省屏幕空间):

int f(int y) {
    int value = -1;
    void *data = NULL;

    if (y < 0)
        goto clean;

    if ((data = malloc(123)) == NULL)
        goto clean;

    /* More code */

    value = 1;
clean:
   free(data);
   return value;
}

就我个人而言，总的来说，我不喜欢箭头编程，而不喜欢多个出口点，尽管两者在正确应用时都很有用。当然，最好的方法是将程序的结构设计成两者都不需要。将你的函数分解成多个块通常会有所帮助:)

尽管在这样做的时候，我发现我最终得到了多个出口点，就像在这个例子中，一些较大的函数被分解成几个较小的函数:

int g(int y) {
  value = 0;

  if ((value = g0(y, value)) == -1)
    return -1;

  if ((value = g1(y, value)) == -1)
    return -1;

  return g2(y, value);
}

根据项目或编码指南的不同，大多数样板代码可以被宏替换。作为旁注，这样分解可以使函数g0、g1、g2非常容易单独测试。

显然，在面向对象和支持异常的语言中，我不会使用这样的if语句(或者根本不会使用，如果我可以用足够少的努力就能摆脱它的话)，代码将更加简单。和non-arrowy。大多数非最终回报可能是例外。

简而言之,

少回报比多回报好 多于一次的返回比巨大的箭头更好，并且保护条款通常是可以的。 在可能的情况下，例外可能/应该取代大多数“保护条款”。

Well, maybe I'm one of the few people here old enough to remember one of the big reasons why "only one return statement" was pushed so hard. It's so the compiler can emit more efficient code. For each function call, the compiler typically pushes some registers on the stack to preserve their values. This way, the function can use those registers for temporary storage. When the function returns, those saved registers have to be popped off the stack and back into the registers. That's one POP (or MOV -(SP),Rn) instruction per register. If you have a bunch of return statements, then either each one has to pop all the registers (which makes the compiled code bigger) or the compiler has to keep track of which registers might have been modified and only pop those (decreasing code size, but increasing compilation time).

今天仍然坚持使用一个return语句的一个原因是易于自动重构。如果您的IDE支持方法提取重构(选择一系列行并将它们转换为一个方法)，那么如果您想提取的行中有一个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语句。

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

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

有些人信得过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是一种糟糕的实践，但我又知道什么呢?所有的理论争论都归结为试图满足一套规则

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

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

懒惰是一种美德 程序员。

使用单一的退出点有好处，就像不可避免的“箭头”编程也有坏处一样。

如果在输入验证或资源分配期间使用多个出口点，我尝试将所有“错误出口”非常明显地放在函数的顶部。

“SSDSLPedia”的Spartan Programming文章和“Portland Pattern Repository’s Wiki”的单一函数出口点文章都对此有一些深刻的争论。当然，还有这篇文章要考虑。

例如，如果您真的需要一个单一的退出点(在任何不支持异常的语言中)，以便在一个地方释放资源，我发现仔细应用goto是很好的;请看这个相当做作的例子(压缩以节省屏幕空间):

int f(int y) {
    int value = -1;
    void *data = NULL;

    if (y < 0)
        goto clean;

    if ((data = malloc(123)) == NULL)
        goto clean;

    /* More code */

    value = 1;
clean:
   free(data);
   return value;
}

就我个人而言，总的来说，我不喜欢箭头编程，而不喜欢多个出口点，尽管两者在正确应用时都很有用。当然，最好的方法是将程序的结构设计成两者都不需要。将你的函数分解成多个块通常会有所帮助:)

尽管在这样做的时候，我发现我最终得到了多个出口点，就像在这个例子中，一些较大的函数被分解成几个较小的函数:

int g(int y) {
  value = 0;

  if ((value = g0(y, value)) == -1)
    return -1;

  if ((value = g1(y, value)) == -1)
    return -1;

  return g2(y, value);
}

根据项目或编码指南的不同，大多数样板代码可以被宏替换。作为旁注，这样分解可以使函数g0、g1、g2非常容易单独测试。

显然，在面向对象和支持异常的语言中，我不会使用这样的if语句(或者根本不会使用，如果我可以用足够少的努力就能摆脱它的话)，代码将更加简单。和non-arrowy。大多数非最终回报可能是例外。

简而言之,

少回报比多回报好 多于一次的返回比巨大的箭头更好，并且保护条款通常是可以的。 在可能的情况下，例外可能/应该取代大多数“保护条款”。

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