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

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语句作为停止执行的命令。

换句话说，如果可能的话，尽量采用这种风格

return a > 0 ?
  positively(a):
  negatively(a);

在这

if (a > 0)
  return positively(a);
else
  return negatively(a);

如果您发现自己编写了几层嵌套的条件，可能有一种方法可以重构它，例如使用谓词列表。如果您发现If和else在语法上相差很大，您可能希望将其分解为更小的函数。跨越超过一屏文本的条件块很难阅读。

没有适用于每一种语言的严格规则。像只有一个return语句这样的东西不会使你的代码好。但是好的代码将允许您以这种方式编写函数。

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

如果可以只写下一个观点，那就是我的观点:

我完全不同意“单返回语句理论”，认为它在代码可读性、逻辑和描述方面都是推测性的，甚至是破坏性的。

使用一次-一次返回的习惯对于纯过程式编程来说都很糟糕，更不用说更高级的抽象(函数式、组合式等)了。此外，我希望所有以这种风格编写的代码都经过一些特殊的重写解析器，使其具有多个返回语句!

一个函数(如果它真的是一个函数/查询，根据“查询-命令分离”注意-见埃菲尔编程语言。例如)必须定义与控制流场景一样多的返回点。它在数学上更加清晰和一致;它是编写函数(即查询)的方法。

但对于你的特工收到的突变信息——程序调用，我不会那么激进。

I've seen it in coding standards for C++ that were a hang-over from C, as if you don't have RAII or other automatic memory management then you have to clean up for each return, which either means cut-and-paste of the clean-up or a goto (logically the same as 'finally' in managed languages), both of which are considered bad form. If your practices are to use smart pointers and collections in C++ or another automatic memory system, then there isn't a strong reason for it, and it become all about readability, and more of a judgement call.