如果管理得当，多次退出是件好事

第一步是明确退出的原因。我的通常是这样的: 1. 不需要执行函数 2. 发现错误 3.提前完成 4. 正常完成 我想你可以把“1”归为一类。不需要执行函数“into”3。提前完成”(如果你愿意的话，可以说是非常提前完成)。

第二步是让函数外部的人知道退出的原因。伪代码看起来像这样:

function foo (input, output, exit_status)

  exit_status == UNDEFINED
  if (check_the_need_to_execute == false) then
    exit_status = NO_NEED_TO_EXECUTE  // reason #1 
    exit

  useful_work

  if (error_is_found == true) then
    exit_status = ERROR               // reason #2
    exit
  if (need_to_go_further == false) then
    exit_status = EARLY_COMPLETION    // reason #3
    exit

  more_work

  if (error_is_found == true) then
    exit_status = ERROR
  else
    exit_status = NORMAL_COMPLETION   // reason #4

end function

显然，如果将上图中的一大块工作移到一个单独的函数中是有益的，那么您应该这样做。

如果您愿意，您可以使用更具体的退出状态，例如，使用几个错误代码和早期完成代码来精确定位退出的原因(甚至位置)。

即使您强制这个函数只有一个出口，我认为您仍然需要指定出口状态。调用者需要知道是否可以使用输出，这有助于维护。

Structured programming says you should only ever have one return statement per function. This is to limit the complexity. Many people such as Martin Fowler argue that it is simpler to write functions with multiple return statements. He presents this argument in the classic refactoring book he wrote. This works well if you follow his other advice and write small functions. I agree with this point of view and only strict structured programming purists adhere to single return statements per function.

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

我更喜欢一个return语句。一个尚未指出的原因是，一些重构工具在单点退出时工作得更好，例如Eclipse JDT提取/内联方法。

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

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