一般来说，我尝试从一个函数中只有一个出口点。然而，有时这样做实际上会创建一个比必要的更复杂的函数体，在这种情况下，最好有多个出口点。它确实需要基于结果的复杂性进行“判断”，但目标应该是在不牺牲复杂性和可理解性的情况下尽可能减少出口点。

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

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

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

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

这主要是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语句。一个尚未指出的原因是，一些重构工具在单点退出时工作得更好，例如Eclipse JDT提取/内联方法。

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

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

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