我认为在不同的情况下，不同的方法更好。例如，如果您应该在返回之前处理返回值，则应该有一个退出点。但在其他情况下，使用多次返回会更舒服。

一个音符。如果在某些情况下，你应该在返回之前处理返回值，但不是所有情况下，最好的解决方案(IMHO)是定义一个像ProcessVal这样的方法，并在返回之前调用它:

var retVal = new RetVal();

if(!someCondition)
    return ProcessVal(retVal);

if(!anotherCondition)
   return retVal;

有人可能会说……如果在执行函数的任务之前必须满足多个条件，那么在满足这些条件之前不要调用函数:

而不是:

function doStuff(foo) {
    if (foo != null) return;
}

Or

function doStuff(foo) {
    if (foo !== null) {
        ...
    }
}

在foo != null之前不要调用doStuff

if(foo != null) doStuff(foo);

这要求每个调用站点确保在调用之前满足调用的条件。如果有多个调用站点，则该逻辑最好放在单独的函数中、待调用函数的方法中(假设它们是一级公民)或代理中。

关于函数是否在数学上是可证明的这个话题，要考虑逻辑而不是语法。如果一个函数有多个返回点，这并不意味着(默认情况下)它在数学上不可证明。

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

我使用多个出口点使错误情况+处理+返回值尽可能接近。

所以必须测试条件a, b, c必须为真，你需要用不同的方式处理它们:

if (a is false) {
    handle this situation (eg. report, log, message, etc.)
    return some-err-code
}
if (b is false) {
    handle this situation
    return other-err-code
}
if (c is false) {
    handle this situation
    return yet-another-err-code
}

perform any action assured that a, b and c are ok.

a, b和c可能是不同的东西，比如a是输入参数检查，b是新分配内存的指针检查，c是检查参数a中的值。

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

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

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

不，因为我们不再生活在20世纪70年代了。如果你的函数足够长以至于多次返回都是个问题，那么它就太长了。

(除了语言中有异常的任何多行函数都会有多个退出点这一事实。)