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

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

我倾向于认为函数中间的return语句是不好的。您可以使用返回在函数的顶部构建一些保护子句，当然也可以告诉编译器在函数的末尾返回什么，但函数中间的返回很容易被忽略，并且会使函数更难解释。

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语句越多，该方法的复杂性就越高。如果您发现自己想知道是否有太多的return语句，那么您可能需要问问自己，该函数中是否有太多的代码行。

但是，不是，一个/多个返回语句并没有错。在某些语言中，这是一种比其他语言(C)更好的实践(c++)。

使用单一出口点可以降低圈复杂度，因此，从理论上讲，可以降低在修改代码时引入错误的可能性。然而，实践往往表明需要更务实的方法。因此，我倾向于只有一个出口点，但如果可读性更好，允许我的代码有多个出口点。

我想说的是，你应该有尽可能多的需要，或者任何使代码更干净的(如保护子句)。

我个人从来没有听过/见过任何“最佳实践”说你应该只有一个返回语句。

在大多数情况下，我倾向于根据逻辑路径尽快退出函数(保护子句就是一个很好的例子)。