这主要是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++编译器中，如果你只从一个地方返回一个值，那么一个返回点可能会生成更好的代码。

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

正如Kent Beck在《实现模式》中讨论保护子句时指出的那样，使一个例程具有单一的入口和出口点……

是为了防止可能的混淆 当你在许多地方跳来跳去 同一例程中的位置。这让 当应用到FORTRAN或 汇编语言程序 有大量的全球数据，甚至 理解哪些语句是 执行是一项艰苦的工作……使用小方法和大部分本地数据，它是不必要的保守。”

我发现用保护子句编写的函数要比一长串嵌套的if then else语句容易理解得多。

我使用多个出口点使错误情况+处理+返回值尽可能接近。

所以必须测试条件a, b, c必须为真，你需要用不同的方式处理它们:

if (a is false) {
    handle this situation (eg. report, log, message, etc.)
    return some-err-code
}
if (b is false) {
    handle this situation
    return other-err-code
}
if (c is false) {
    handle this situation
    return yet-another-err-code
}

perform any action assured that a, b and c are ok.

a, b和c可能是不同的东西，比如a是输入参数检查，b是新分配内存的指针检查，c是检查参数a中的值。

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

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

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

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

懒惰是一种美德 程序员。

有人可能会说……如果在执行函数的任务之前必须满足多个条件，那么在满足这些条件之前不要调用函数:

而不是:

function doStuff(foo) {
    if (foo != null) return;
}

Or

function doStuff(foo) {
    if (foo !== null) {
        ...
    }
}

在foo != null之前不要调用doStuff

if(foo != null) doStuff(foo);

这要求每个调用站点确保在调用之前满足调用的条件。如果有多个调用站点，则该逻辑最好放在单独的函数中、待调用函数的方法中(假设它们是一级公民)或代理中。

关于函数是否在数学上是可证明的这个话题，要考虑逻辑而不是语法。如果一个函数有多个返回点，这并不意味着(默认情况下)它在数学上不可证明。

拥有多个出口点本质上与使用GOTO是一样的。这是不是件坏事取决于你对迅猛龙的看法。