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

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]
}

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

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.

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

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

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

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

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

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

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

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

我可能会因此被讨厌，但理想情况下，我认为根本不应该有return语句，函数应该只返回它最后一个表达式，在完全理想的情况下，应该只包含一个。

所以不

function name(arg) {
    if (arg.failure?)
        return;

    //code for non failure
}

而是

function name(arg) {
    if (arg.failure?)
        voidConstant
    else {
        //code for non failure


}

不是表达式的if语句和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.