没有人提到或引用代码完成，所以我就这么做。

17.1返回

尽量减少每个例程的返回次数。如果在底部阅读一个例程，你没有意识到它可能会返回到上面的某个地方，那么理解它就更难了。

在增强可读性时使用返回。在某些例程中，一旦知道了答案，就希望立即将其返回给调用例程。如果例程以不需要任何清理的方式定义，则不立即返回意味着必须编写更多代码。

总是要求单一的返回类型是没有意义的。我认为这更像是一个标志，表明某些东西可能需要简化。有时有多个回报是必要的，但通常你可以通过至少尝试有一个退出点来简化事情。

如果你最终得到了很多返回值，那么你的代码可能有问题。否则，我同意有时能够从子例程的多个位置返回是很好的，特别是当它使代码更干净的时候。

Perl 6:坏例子

sub Int_to_String( Int i ){
  given( i ){
    when 0 { return "zero" }
    when 1 { return "one" }
    when 2 { return "two" }
    when 3 { return "three" }
    when 4 { return "four" }
    ...
    default { return undef }
  }
}

这样写会更好吗

Perl 6:好例子

@Int_to_String = qw{
  zero
  one
  two
  three
  four
  ...
}
sub Int_to_String( Int i ){
  return undef if i < 0;
  return undef unless i < @Int_to_String.length;
  return @Int_to_String[i]
}

注意，这只是一个简单的例子

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

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

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

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

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

第一步是明确退出的原因。我的通常是这样的: 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

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

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

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