在一个没有副作用的函数中，没有理由有多个返回值，你应该用函数式的风格来编写它们。在有副作用的方法中，事情更有顺序(时间索引)，因此您使用命令式风格编写，使用return语句作为停止执行的命令。

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

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

在这

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

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

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

你知道有句谚语——情人眼里出西施。

有些人信得过NetBeans，有些人信得过IntelliJ IDEA，有些人信得过Python，有些人信得过PHP。

在一些商店，如果你坚持这样做，你可能会丢掉工作:

public void hello()
{
   if (....)
   {
      ....
   }
}

这个问题完全是关于可见性和可维护性。

I am addicted to using boolean algebra to reduce and simplify logic and use of state machines. However, there were past colleagues who believed my employ of "mathematical techniques" in coding is unsuitable, because it would not be visible and maintainable. And that would be a bad practice. Sorry people, the techniques I employ is very visible and maintainable to me - because when I return to the code six months later, I would understand the code clearly rather seeing a mess of proverbial spaghetti.

嘿，伙计(就像一个前客户曾经说过的)，做你想做的，只要你知道如何在我需要你解决它的时候解决它。

I remember 20 years ago, a colleague of mine was fired for employing what today would be called agile development strategy. He had a meticulous incremental plan. But his manager was yelling at him "You can't incrementally release features to users! You must stick with the waterfall." His response to the manager was that incremental development would be more precise to customer's needs. He believed in developing for the customers needs, but the manager believed in coding to "customer's requirement".

我们经常因为打破数据规范化、MVP和MVC边界而感到内疚。我们内联而不是构造函数。我们走捷径。

就我个人而言，我认为PHP是一种糟糕的实践，但我又知道什么呢?所有的理论争论都归结为试图满足一套规则

质量=精度，可维护性 和盈利能力。

所有其他规则都退居幕后。当然，这条规则永远不会消失:

懒惰是一种美德 程序员。

Well, maybe I'm one of the few people here old enough to remember one of the big reasons why "only one return statement" was pushed so hard. It's so the compiler can emit more efficient code. For each function call, the compiler typically pushes some registers on the stack to preserve their values. This way, the function can use those registers for temporary storage. When the function returns, those saved registers have to be popped off the stack and back into the registers. That's one POP (or MOV -(SP),Rn) instruction per register. If you have a bunch of return statements, then either each one has to pop all the registers (which makes the compiled code bigger) or the compiler has to keep track of which registers might have been modified and only pop those (decreasing code size, but increasing compilation time).

今天仍然坚持使用一个return语句的一个原因是易于自动重构。如果您的IDE支持方法提取重构(选择一系列行并将它们转换为一个方法)，那么如果您想提取的行中有一个return语句，特别是如果您正在返回一个值，则很难做到这一点。

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

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

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

我想说，武断地决定不使用多个出口点是非常不明智的，因为我发现这种技术在实践中一次又一次地有用，事实上，为了清晰起见，我经常将现有的代码重构为多个出口点。我们可以这样比较这两种方法:-

string fooBar(string s, int? i) {
  string ret = "";
  if(!string.IsNullOrEmpty(s) && i != null) {
    var res = someFunction(s, i);

    bool passed = true;
    foreach(var r in res) {
      if(!r.Passed) {
        passed = false;
        break;
      }
    }

    if(passed) {
      // Rest of code...
    }
  }

  return ret;
}

将此与允许多个出口点的代码进行比较

string fooBar(string s, int? i) {
  var ret = "";
  if(string.IsNullOrEmpty(s) || i == null) return null;

  var res = someFunction(s, i);

  foreach(var r in res) {
      if(!r.Passed) return null;
  }

  // Rest of code...

  return ret;
}

我认为后者要清楚得多。据我所知，现在对多个退出点的批评是一种相当过时的观点。

对于足够小的函数来说，多个出口点很好——也就是说，可以在一个屏幕长度上完整地查看函数。如果一个冗长的函数同样包含多个出口点，则表明该函数可以进一步分割。

也就是说，除非绝对必要，否则我避免使用多出口功能。在更复杂的函数中，由于一些模糊的行中出现的一些错误返回，我感到了错误的痛苦。