“仅返回”的概念从何而来？

我经常跟程序员谁说：“ 不要把多个return语句相同的方法。 ”当我问他们告诉我的原因，我得到的是“ 编码标准是这么说的。 ”或者“ 这是令人困惑的。 ”当他们通过单个return语句向我展示解决方案时，代码对我来说看起来更难看。例如：

if (condition)
   return 42;
else
   return 97;

“ 这很丑，您必须使用局部变量！ ”

int result;
if (condition)
   result = 42;
else
   result = 97;
return result;

50％的代码膨胀如何使程序更易于理解？我个人觉得比较困难，因为状态空间刚刚增加了另一个很容易避免的变量。

当然，通常我会写：

return (condition) ? 42 : 97;

但是许多程序员避免使用条件运算符，而是喜欢长格式。

“仅返回”的概念从何而来？产生这种约定是否有历史原因？

当大多数编程以汇编语言，FORTRAN或COBOL完成时，将编写“单入口，单出口”。它被广泛误解了，因为现代语言不支持Dijkstra所警告的做法。

“单一入口”表示“不为功能创建替代入口点”。当然，使用汇编语言，可以在任何指令中输入功能。FORTRAN通过以下ENTRY语句支持功能的多个条目：

      SUBROUTINE S(X, Y)
      R = SQRT(X*X + Y*Y)
C ALTERNATE ENTRY USED WHEN R IS ALREADY KNOWN
      ENTRY S2(R)
      ...
      RETURN
      END

C USAGE
      CALL S(3,4)
C ALTERNATE USAGE
      CALL S2(5)

“单退出”意味着一个函数只能返回到一处：该语句立即呼叫以下。这并不意味着一个函数只能从一个地方返回。当结构化编程是书面的，它是常见的做法如下功能通过返回到备用位置指示错误。FORTRAN通过“备用回报”支持此操作：

C SUBROUTINE WITH ALTERNATE RETURN.  THE '*' IS A PLACE HOLDER FOR THE ERROR RETURN
      SUBROUTINE QSOLVE(A, B, C, X1, X2, *)
      DISCR = B*B - 4*A*C
C NO SOLUTIONS, RETURN TO ERROR HANDLING LOCATION
      IF DISCR .LT. 0 RETURN 1
      SD = SQRT(DISCR)
      DENOM = 2*A
      X1 = (-B + SD) / DENOM
      X2 = (-B - SD) / DENOM
      RETURN
      END

C USE OF ALTERNATE RETURN
      CALL QSOLVE(1, 0, 1, X1, X2, *99)
C SOLUTION FOUND
      ...
C QSOLVE RETURNS HERE IF NO SOLUTIONS
99    PRINT 'NO SOLUTIONS'

这两种技术都很容易出错。使用备用条目通常会使一些变量未初始化。使用替代返回有一个GOTO语句的所有问题，另外一个复杂的问题是分支条件不是与分支相邻，而是在子例程中的某个位置。

这种观念单入口，单出口（SESE）来自具有明确资源管理语言，如C语言和汇编。在C中，这样的代码将泄漏资源：

void f()
{
  resource res = acquire_resource();  // think malloc()
  if( f1(res) )
    return; // leaks res
  f2(res);
  release_resource(res);  // think free()
}

在这种语言中，您基本上有三个选择：

• 复制清除代码。
  啊。冗余总是不好的。

• 使用a goto跳至清除代码。
  这要求清除代码是函数中的最后一件事。（这就是为什么有人认为它goto有其地位的原因。并且确实存在于-C中。）

• 引入局部变量并通过该变量操纵控制流。
  缺点是通过语法操纵该控制流程（想到break，return，if，while）是更容易跟踪不是通过变量的状态操作控制流程（因为这些变量都没有的状态，当你在算法）。

在汇编中，这甚至很奇怪，因为调用该函数时您可以跳转到函数中的任何地址，这实际上意味着您几乎可以无限地访问任何函数。（有时这很有用。此类重击是编译器实现C ++多继承场景中this调用virtual函数所需的指针调整的常用技术。）

当您必须手动管理资源时，利用在任何地方进入或退出函数的选项都会导致更复杂的代码，从而导致错误。因此，出现了一种传播SESE的思想流派，以便获得更简洁的代码和更少的错误。

但是，当一种语言具有异常功能时，（几乎）任何功能都可能在（几乎）任何点过早退出，因此无论如何都需要为过早返回做好准备。（我认为finally主要用于Java和using（在实现时IDisposable，finally否则）在C＃中；在C ++中使用RAII。）完成此操作后，您不会因为提早return声明而对自己进行清理，所以可能是支持SESE的最有力论据消失了。

留下可读性。当然，带有六条return语句的200 LoC函数随机散布在该函数上并不是很好的编程风格，也不是可读代码。但是，如果没有这些过早的返回，这样的功能也不容易理解。

在没有或不应手动管理资源的语言中，遵守旧的SESE约定几乎没有价值。就像我上面所说的OTOH，SESE通常会使代码更加复杂。这是一种恐龙（除C之外）不能很好地适应当今的大多数语言。它没有帮助提高代码的可理解性，反而阻碍了它。

Java程序员为什么要坚持这一点？我不知道，但是从我的POV（外部）来看，Java从C（它们有意义的地方）采纳了许多约定，并将它们应用于其OO世界（在这里它们是无用的或完全坏的），现在它遵循他们，无论付出什么代价。（按照惯例，在作用域的开头定义所有变量。）

出于非理性的原因，程序员会坚持使用各种奇怪的符号。（深层嵌套的结构化语句（“箭头”）在Pascal之类的语言中曾经被视为漂亮的代码。）对此应用纯逻辑推理似乎无法说服大多数人偏离既定方式。改变这种习惯的最好方法可能是早日教他们做最好的事情，而不是常规的事情。作为编程老师，您可以掌握它。:)

一方面，单个return语句使日志记录以及依赖日志记录的调试形式更加容易。我记得很多次我不得不将函数简化为单返回值，只是为了单点打印出返回值。

  int function() {
     if (bidi) { print("return 1"); return 1; }
     for (int i = 0; i < n; i++) {
       if (vidi) { print("return 2"); return 2;}
     }
     print("return 3");
     return 3;
  }

另一方面，您可以将其重构为function()调用_function()并记录结果。

“单项进入，单项退出”起源于1970年代初期的结构化编程革命，该革命由Edsger W. Dijkstra致编辑的信“ GOTO声明被认为有害 ”开始。在Ole Johan-Dahl，Essger W. Dijkstra和Charles Anthony Richard Hoare所著的经典著作“ Structured Programming”中详细介绍了结构化编程背后的概念。

即使在今天，也必须阅读“被认为有害的GOTO声明”。“结构化程序设计”已经过时，但仍然非常非常有益，应该在任何开发人员的“必读”列表中排在首位，远远超过史蒂夫·麦康奈尔。（Dahl的部分介绍了Simula 67中的类基础知识，它们是C ++和所有面向对象编程中类的技术基础。）

链接Fowler总是很容易的。

违反SESE的主要示例之一是保护子句：

用警卫条款代替嵌套条件

在所有特殊情况下使用警卫条款

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
return result;
};  

                                                                                                        

double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
};  

有关更多信息，请参见“ 重构 ...的第250页” 。

不久前，我就此主题写了一篇博客文章。

最重要的是，该规则来自没有垃圾收集或异常处理的语言的时代。没有正式的研究表明该规则可以导致现代语言中更好的代码。只要这会导致代码更短或更易读，就可以忽略它。坚持这一点的Java专家遵循过时的，毫无意义的规则而盲目且毫无疑问。

在Stackoverflow上也曾问过这个问题

一回就可以简化重构。尝试对包含返回，中断或继续的for循环的内部执行“提取方法”。由于您破坏了控制流程，这将失败。

关键是：我想没人会假装编写完美的代码。因此，代码在重构时通常会被“改进”和扩展。因此，我的目标是保持代码尽可能友好的重构。

我经常遇到这样的问题：如果函数包含控制流中断器，并且我只想添加很少的功能，则必须完全重新构造函数。当您更改整个控制流，而不是将新的路径引入隔离的嵌套时，这很容易出错。如果最后只有一个返回，或者如果使用保护退出循环，那么您当然会有更多的嵌套和更多的代码。但是您可以获得编译器和IDE支持的重构功能。

考虑以下事实：多个return语句等效于将GOTO包含到单个return语句中。这与break语句相同。因此，像我一样，有些人出于所有意图和目的都将它们视为GOTO。

但是，我认为这些类型的GOTO并不有害，如果我有充分的理由，我会毫不犹豫地在代码中使用实际的GOTO。

我的一般规则是GOTO仅用于流控制。绝对不要将它们用于任何循环，也永远不要转到“向上”或“向后”。（这是中断/返回的工作方式）

正如其他人提到的那样，以下是必须阅读的 认为有害的GOTO声明。
但是，请记住，这是在1970年编写的，当时GOTO的使用方式被过度使用。并非每个GOTO都是有害的，只要您不使用它们而不是常规构造，我就不会劝阻它们的使用，但是在奇怪的情况下，使用常规构造会非常不便。

我发现在由于错误而需要逃逸区域的错误情况下使用它们，在正常情况下有时永远都不会发生，这很有用。但是，您还应该考虑将此代码放入单独的函数中，以便您可以提早返回而不是使用GOTO ...，但是有时这也很不方便。

圈复杂度

我已经看到SonarCube使用多个return语句来确定圈复杂度。因此，返回语句越多，圈复杂度就越高

退货类型变更

多次返回意味着当我们决定改变返回类型时，我们需要在函数中的多个位置进行改变。

多次退出

调试起来比较困难，因为需要结合条件语句仔细研究逻辑，以了解导致返回值的原因。

重构解决方案

多个return语句的解决方案是在解决所需的实现对象后，将其替换为具有单条返回值的多态。