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

我倾向于单一退出，除非事情真的变得复杂。我发现在某些情况下，多个存在点可以掩盖其他更重要的设计问题:

public void DoStuff(Foo foo)
{
    if (foo == null) return;
}

在看到这段代码时，我马上会问:

'foo'是否为空? 如果是这样，有多少客户端'DoStuff'曾经调用一个空'foo'函数?

根据这些问题的答案，可能是这样

这种检查毫无意义，因为它从来都不是真的。它应该是一个断言) 这种检查很少是正确的，所以最好改变那些特定的调用函数，因为它们可能应该采取一些其他的操作。

在上述两种情况下，代码可能都可以用断言重做，以确保'foo'永远不为空，并更改相关的调用者。

还有另外两个原因(我认为是针对c++代码的)，多重存在实际上会产生负面影响。它们是代码大小和编译器优化。

在函数出口作用域中的非pod c++对象将调用其析构函数。如果有几个return语句，那么作用域中可能有不同的对象，因此要调用的析构函数列表也会不同。因此，编译器需要为每个return语句生成代码:

void foo (int i, int j) {
  A a;
  if (i > 0) {
     B b;
     return ;   // Call dtor for 'b' followed by 'a'
  }
  if (i == j) {
     C c;
     B b;
     return ;   // Call dtor for 'b', 'c' and then 'a'
  }
  return 'a'    // Call dtor for 'a'
}

如果代码大小是一个问题，那么这可能是值得避免的。

另一个问题涉及到“命名返回值优化”(又名复制省略，ISO c++ '03 12.8/15)。c++允许实现在可以的情况下跳过调用复制构造函数:

A foo () {
  A a1;
  // do something
  return a1;
}

void bar () {
  A a2 ( foo() );
}

就像代码一样，对象'a1'是在'foo'中构造的，然后它的复制构造将被调用来构造'a2'。然而，复制省略允许编译器在堆栈上与'a2'相同的位置构造'a1'。因此，当函数返回时，不需要“复制”对象。

多个出口点会使编译器的检测工作复杂化，至少对于相对较新的vc++版本，优化不会发生在函数体有多个返回的地方。有关详细信息，请参阅Visual c++ 2005中的命名返回值优化。

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

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

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

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

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

由于错误处理，您已经隐式地拥有多个隐式返回语句，因此要处理它。

但是，就像编程中的典型情况一样，有支持和反对多次返回实践的例子。如果它能让代码更清晰，那就这样做。使用许多控制结构会有所帮助(例如case语句)。

I lean towards using guard clauses to return early and otherwise exit at the end of a method. The single entry and exit rule has historical significance and was particularly helpful when dealing with legacy code that ran to 10 A4 pages for a single C++ method with multiple returns (and many defects). More recently, accepted good practice is to keep methods small which makes multiple exits less of an impedance to understanding. In the following Kronoz example copied from above, the question is what occurs in //Rest of code...?:

void string fooBar(string s, int? i) {

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

我意识到这个例子有点做作，但我很想把foreach循环重构成一个LINQ语句，然后将其视为一个保护子句。同样，在一个人为的例子中，代码的意图并不明显，someFunction()可能会有一些其他副作用，或者结果可能会在代码的// Rest中使用....

if (string.IsNullOrEmpty(s) || i == null) return null;
if (someFunction(s, i).Any(r => !r.Passed)) return null;

给出以下重构函数:

void string fooBar(string s, int? i) {

  if (string.IsNullOrEmpty(s) || i == null) return null;
  if (someFunction(s, i).Any(r => !r.Passed)) return null;

  // Rest of code...

  return ret;
}

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

有些人信得过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是一种糟糕的实践，但我又知道什么呢?所有的理论争论都归结为试图满足一套规则

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

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

懒惰是一种美德 程序员。