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

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

总是要求单一的返回类型是没有意义的。我认为这更像是一个标志，表明某些东西可能需要简化。有时有多个回报是必要的，但通常你可以通过至少尝试有一个退出点来简化事情。

我想说的是，你应该有尽可能多的需要，或者任何使代码更干净的(如保护子句)。

我个人从来没有听过/见过任何“最佳实践”说你应该只有一个返回语句。

在大多数情况下，我倾向于根据逻辑路径尽快退出函数(保护子句就是一个很好的例子)。

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

而不是:

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

Or

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

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

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

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

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

函数中return语句越多，该方法的复杂性就越高。如果您发现自己想知道是否有太多的return语句，那么您可能需要问问自己，该函数中是否有太多的代码行。

但是，不是，一个/多个返回语句并没有错。在某些语言中，这是一种比其他语言(C)更好的实践(c++)。

我相信多次返回通常是好的(在我用c#编写的代码中)。单返回样式是从C语言中保留下来的，但是您可能没有用C语言编写代码。

在所有编程语言中，没有法律要求一个方法只有一个退出点。有些人坚持这种风格的优越性，有时他们把它提升为“规则”或“法律”，但这种信念没有任何证据或研究支持。

在C代码中，多个返回样式可能是一个坏习惯，资源必须显式地去分配，但Java、c#、Python或JavaScript等语言具有自动垃圾收集和try. finally块(以及在c#中使用块)等构造，并且这个参数不适用-在这些语言中，需要集中的手动资源回收是非常罕见的。

在某些情况下，单个返回值可读性更好，而在某些情况下则不是这样。看看它是否减少了代码行数，使逻辑更清晰，或减少了大括号、缩进或临时变量的数量。

因此，根据你的艺术感受使用尽可能多的返回，因为这是一个布局和可读性问题，而不是技术问题。

我在我的博客上详细地讨论过这个问题。