是否有充分的理由说明在函数中只有一个 return 语句是一种更好的做法？
或者只要逻辑正确就可以从函数中返回，这意味着函数中可能有很多返回语句？
【问题讨论】：
标签： language-agnostic coding-style
我经常在一个方法的开头有几个语句来返回“简单”的情况。例如，这个：
public void DoStuff(Foo foo)
{
if (foo != null)
{
...
}
}
...可以像这样变得更具可读性（恕我直言）：
public void DoStuff(Foo foo)
{
if (foo == null) return;
...
}
所以是的，我认为从一个函数/方法中有多个“退出点”很好。
【讨论】：
DoStuff() { DoStuffInner(); IncreaseStuffCallCounter(); }
没有人提到或引用Code Complete，所以我会这样做。
尽量减少每个例程中的返回次数。如果在底部阅读例程时，您没有意识到它返回到上面某个地方的可能性，则更难理解例程。
在提高可读性时使用 return。在某些例程中，一旦您知道答案，就想立即将其返回给调用例程。如果例程以不需要任何清理的方式定义，则不立即返回意味着您必须编写更多代码。
【讨论】：
我会说任意决定反对多个出口点是非常不明智的，因为我发现该技术在实践中非常有用一遍又一遍，事实上我经常重构为清楚起见，将现有代码复制到多个退出点。我们可以这样比较这两种方法：-
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;
}
我认为后者要清楚得多。据我所知，现在对多个出口点的批评是一种相当陈旧的观点。
【讨论】：
我目前正在开发一个代码库，其中两个工作人员盲目地赞同“单点退出”理论，我可以根据经验告诉你，这是一种可怕的可怕做法。它使代码极难维护，我会告诉你原因。
使用“单点退出”理论，您不可避免地会得到如下所示的代码：
function()
{
HRESULT error = S_OK;
if(SUCCEEDED(Operation1()))
{
if(SUCCEEDED(Operation2()))
{
if(SUCCEEDED(Operation3()))
{
if(SUCCEEDED(Operation4()))
{
}
else
{
error = OPERATION4FAILED;
}
}
else
{
error = OPERATION3FAILED;
}
}
else
{
error = OPERATION2FAILED;
}
}
else
{
error = OPERATION1FAILED;
}
return error;
}
这不仅使代码很难理解，而且现在说你需要返回并在 1 和 2 之间添加一个操作。你必须缩进整个该死的函数，祝你好运确保您的所有 if/else 条件和大括号都正确匹配。
这种方法使代码维护极其困难且容易出错。
【讨论】：
Structured programming 说每个函数只应该有一个返回语句。这是为了限制复杂性。许多人（例如 Martin Fowler）认为编写具有多个返回语句的函数更简单。他在他写的经典refactoring 书中提出了这个论点。如果您遵循他的其他建议并编写小函数，这将很有效。我同意这个观点，只有严格的结构化编程纯粹主义者才会遵守每个函数的单个返回语句。
【讨论】：
GOTO 来移动控制流，即使函数存在。它从不说“永远不要使用GOTO”。
正如 Kent Beck 在讨论 Implementation Patterns 中的保护子句时指出的那样，使例程只有一个入口和出口点......
"是为了防止可能的混淆 当跳进跳出许多 在同一例程中的位置。它使 应用于 FORTRAN 或 编写的汇编语言程序 有大量的全球数据，甚至 了解哪些陈述是 执行起来很辛苦……使用小方法和主要是本地数据，这是不必要的保守。”
我发现使用保护子句编写的函数比一长串嵌套的 if then else 语句更容易理解。
【讨论】：
在没有副作用的函数中，没有充分的理由有多个返回值，您应该以函数式风格编写它们。在具有副作用的方法中，事情更具有顺序性（时间索引），因此您以命令式风格编写，使用 return 语句作为停止执行的命令。
换句话说，如果可能的话，喜欢这种风格
return a > 0 ?
positively(a):
negatively(a);
在此
if (a > 0)
return positively(a);
else
return negatively(a);
如果您发现自己编写了多层嵌套条件，则可能有一种方法可以重构它，例如使用谓词列表。如果您发现 if 和 else 在语法上相距甚远，您可能希望将其分解为更小的函数。跨越一屏文本的条件块很难阅读。
没有适用于所有语言的硬性规定。像只有一个 return 语句这样的东西不会让你的代码变好。但好的代码往往会让你以这种方式编写函数。
【讨论】：
我在 C++ 的编码标准中看到它是 C 的遗留问题，好像你没有 RAII 或其他自动内存管理，那么你必须为每次返回进行清理，这要么意味着削减 - and-paste 清理或 goto（逻辑上与托管语言中的“finally”相同），这两者都被认为是错误的形式。如果您的实践是在 C++ 或其他自动内存系统中使用智能指针和集合，那么就没有充分的理由这样做，而这一切都与可读性有关，更多的是一种判断调用。
【讨论】：
auto_ptr 时会产生一些开销，则可以并行使用普通指针。尽管首先使用非优化编译器编写“优化”代码会很奇怪。
try ... finally ) 并且您需要进行资源维护，您可以在方法结束时使用单个返回来完成。在你这样做之前，你应该认真考虑重构代码以摆脱这种情况。
我倾向于认为函数中间中的返回语句是不好的。您可以使用返回在函数顶部构建一些保护子句，当然可以告诉编译器在函数末尾返回什么而没有问题，但在函数的 middle 中返回可能很容易被遗漏，并且会使函数更难解释。
【讨论】：
是否有充分的理由说明在函数中只有一个 return 语句是一种更好的做法？
是的，有：
这个问题通常被认为是多重返回或深度嵌套的 if 语句之间的错误二分法。几乎总是有第三种解决方案，它是非常线性的（没有深度嵌套），只有一个出口点。
更新：显然MISRA guidelines promote single exit也是。
需要明确的是，我并不是说多次退货总是是错误的。但考虑到其他等效的解决方案，有很多充分的理由更喜欢单回报的解决方案。
【讨论】：
Contract.Ensures 与多个返回点一起使用。
goto 来获取常见的清理代码，那么您可能已经简化了函数，以便在清理结束时有一个return代码。所以你可以说你已经用goto 解决了这个问题，但我会说你通过简化为一个return 来解决它。
具有单个退出点确实在调试中提供了优势，因为它允许您在函数末尾设置单个断点以查看实际返回的值。
【讨论】：
一般来说，我尝试从一个函数中只设置一个退出点。然而，有时这样做实际上最终会创建一个比必要的更复杂的函数体，在这种情况下，最好有多个退出点。它确实必须是基于产生的复杂性的“判断调用”，但目标应该是在不牺牲复杂性和可理解性的情况下尽可能少的退出点。
【讨论】：
不，因为we don't live in the 1970s any more。如果你的函数足够长以至于多次返回是个问题，那就太长了。
（除此之外，语言中的任何多行函数都会有多个退出点。）
【讨论】：
我更喜欢单次退出，除非它真的使事情复杂化。我发现在某些情况下，多个存在点可以掩盖其他更重要的设计问题：
public void DoStuff(Foo foo)
{
if (foo == null) return;
}
看到这段代码，我立马问：
根据这些问题的答案，可能是这样的
在上述两种情况下，代码可能都可以通过断言重新编写，以确保 'foo' 永远不会为 null 并且相关的调用者已更改。
还有另外两个原因（我认为具体到 C++ 代码）存在多个实际上会产生负面影响。它们是代码大小和编译器优化。
函数出口处范围内的非 POD C++ 对象将调用其析构函数。在有多个 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++ 版本，在函数体有多个返回的情况下没有进行优化。详情请见Named Return Value Optimization in Visual C++ 2005。
【讨论】：
throw new ArgumentNullException() 也是如此），我真的很喜欢您的其他考虑，它们是对我来说都是有效的，并且在某些利基环境中可能很关键。
foo被测试的问题与主题无关，是做if (foo == NULL) return; dowork; 还是if (foo != NULL) { dowork; }
只有一个退出点会减少Cyclomatic Complexity，因此，理论上会降低您在更改代码时将错误引入代码的可能性。然而，实践往往表明需要一种更务实的方法。因此，我的目标是拥有一个退出点，但如果这样更具可读性，则允许我的代码拥有多个退出点。
【讨论】：
我强迫自己只使用一个return 语句，因为它在某种意义上会产生代码异味。让我解释一下：
function isCorrect($param1, $param2, $param3) {
$toret = false;
if ($param1 != $param2) {
if ($param1 == ($param3 * 2)) {
if ($param2 == ($param3 / 3)) {
$toret = true;
} else {
$error = 'Error 3';
}
} else {
$error = 'Error 2';
}
} else {
$error = 'Error 1';
}
return $toret;
}
（条件随意……）
条件越多，函数越大，越难阅读。因此，如果您适应了代码气味，您就会意识到这一点，并想要重构代码。两种可能的解决方案是：
多次退货
function isCorrect($param1, $param2, $param3) {
if ($param1 == $param2) { $error = 'Error 1'; return false; }
if ($param1 != ($param3 * 2)) { $error = 'Error 2'; return false; }
if ($param2 != ($param3 / 3)) { $error = 'Error 3'; return false; }
return true;
}
分离功能
function isEqual($param1, $param2) {
return $param1 == $param2;
}
function isDouble($param1, $param2) {
return $param1 == ($param2 * 2);
}
function isThird($param1, $param2) {
return $param1 == ($param2 / 3);
}
function isCorrect($param1, $param2, $param3) {
return !isEqual($param1, $param2)
&& isDouble($param1, $param3)
&& isThird($param2, $param3);
}
当然，它更长而且有点乱，但是在以这种方式重构函数的过程中，我们已经
【讨论】：
我会说你应该有尽可能多的，或者任何使代码更清晰的东西（例如guard clauses）。
我个人从未听过/见过任何“最佳做法”说您应该只有一份退货声明。
在大多数情况下，我倾向于根据逻辑路径尽快退出函数（保护子句就是一个很好的例子）。
【讨论】：
我相信多次返回通常是好的（在我用 C# 编写的代码中）。单返回样式是从 C 中保留下来的。但是您可能不是在 C 中编码。
没有法律要求所有编程语言中的方法只有一个退出点。有些人坚持这种风格的优越性，有时他们将其提升为“规则”或“法律”，但这种信念没有任何证据或研究支持。
在 C 代码中使用多种返回样式可能是一个坏习惯，其中必须显式释放资源，但 Java、C#、Python 或 JavaScript 等具有自动垃圾回收和try..finally 等构造的语言块（和 C# 中的 using 块），并且此参数不适用 - 在这些语言中，需要集中手动释放资源是非常罕见的。
在某些情况下，单个返回更具可读性，而在某些情况下则不是。看看它是否减少了代码行数，使逻辑更清晰或减少了大括号和缩进或临时变量的数量。
因此，根据您的艺术感受使用尽可能多的回报，因为这是布局和可读性问题，而不是技术问题。
【讨论】：
有一个单一的退出点有好处，正如不可避免的"arrow" 编程产生的坏话一样。
如果在输入验证或资源分配期间使用多个退出点，我会尝试将所有“错误退出”非常明显地放在函数的顶部。
“SSDSLPedia”的Spartan Programming 文章和“Portland Pattern Repository's Wiki”的the single function exit point 文章对此都有一些深刻的论据。当然，还有这篇文章要考虑。
如果你真的想要一个退出点（在任何非异常启用的语言中），例如为了在一个地方释放资源，我发现仔细应用 goto 是好的；例如，请参阅这个相当人为的示例（压缩以节省屏幕空间）：
int f(int y) {
int value = -1;
void *data = NULL;
if (y < 0)
goto clean;
if ((data = malloc(123)) == NULL)
goto clean;
/* More code */
value = 1;
clean:
free(data);
return value;
}
就我个人而言，一般来说，我不喜欢箭头编程多于不喜欢多个出口点，尽管正确应用时两者都很有用。当然，最好的办法是将您的程序结构为两者都不需要。将你的函数分解成多个块通常会有所帮助:)
虽然这样做时，我发现我最终会得到多个退出点，如本例所示，其中一些较大的函数已分解为几个较小的函数：
int g(int y) {
value = 0;
if ((value = g0(y, value)) == -1)
return -1;
if ((value = g1(y, value)) == -1)
return -1;
return g2(y, value);
}
根据项目或编码指南，大部分样板代码都可以用宏代替。作为旁注，以这种方式分解它使得函数 g0、g1、g2 非常容易单独测试。
显然，在面向 OO 和启用异常的语言中，我不会使用这样的 if 语句（或者根本不会使用它，如果我可以毫不费力地摆脱它），并且代码会更加简单.并且非箭头。大多数非最终回报可能是例外。
总之;
【讨论】：
您知道这句格言 - 情人眼中的美。
有些人发誓NetBeans，有些人发誓IntelliJ IDEA，有些人发誓Python，有些人发誓PHP。
如果你坚持这样做，你可能会失去工作：
public void hello()
{
if (....)
{
....
}
}
问题在于可见性和可维护性。
我沉迷于使用布尔代数来减少和简化逻辑以及状态机的使用。但是，过去的同事认为我在编码中使用“数学技术”是不合适的，因为它不可见且不可维护。那将是一个不好的做法。抱歉，我所使用的技术对我来说是非常可见和可维护的——因为当我六个月后回到代码时，我会清楚地理解代码，而不是看到一团糟的意大利面条。
嘿伙计（就像以前的客户常说的那样）做你想做的事，只要你知道如何在我需要你修复它时修复它。
我记得 20 年前，我的一位同事因为采用了今天称为agile development 的策略而被解雇。他有一个细致的增量计划。但他的经理对他大喊“你不能增量地向用户发布功能！你必须坚持使用waterfall。”他对经理的回应是，渐进式开发将更准确地满足客户的需求。他相信为客户的需求而开发，但经理相信编码是“客户的要求”。
我们经常因打破数据规范化、MVP 和 MVC 界限而感到内疚。我们内联而不是构造函数。我们走捷径。
就个人而言，我认为 PHP 是不好的做法，但我知道什么。所有的理论论证归结为试图满足一套规则
质量 = 精度、可维护性 和盈利能力。
所有其他规则都淡入背景。当然，这条规则永远不会消失：
懒惰是善的美德 程序员。
【讨论】：
我倾向于使用保护子句提前返回，否则在方法结束时退出。单一进入和退出规则具有历史意义，并且在处理具有多个返回（和许多缺陷）的单个 C++ 方法运行到 10 A4 页的遗留代码时特别有用。最近，公认的良好做法是保持方法小，这使得多个出口对理解的阻碍更小。在从上面复制的以下 Kronoz 示例中，问题是 //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() 可能有其他一些副作用，或者结果可能会在 // 其余代码中使用。 ..
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;
}
【讨论】：
null而不是抛出异常表明参数不被接受呢？
我能想到的一个很好的理由是代码维护：您有一个单点退出。如果您想更改结果的格式，...，实现起来要简单得多。另外，为了调试，你可以在那里设置一个断点:)
话虽如此，我曾经不得不在一个库中工作，那里的编码标准规定“每个函数一个返回语句”，我发现这非常困难。我写了很多数值计算代码，而且经常有“特殊情况”，所以代码最终很难理解......
【讨论】：
对于足够小的函数来说，多个退出点是可以的——也就是说，一个可以在一个屏幕长度上完整查看的函数。如果一个冗长的函数同样包含多个退出点，则表明该函数可以进一步细分。
也就是说我避免使用多个退出函数除非绝对必要。在更复杂的函数中，由于一些模糊的行中的一些杂散返回，我感到很痛苦。
【讨论】：
我曾使用过糟糕的编码标准，这些标准会强制您使用单一的退出路径，如果该功能不是微不足道的，那么结果几乎总是非结构化的意大利面条 - 您最终会遇到很多中断并继续，只是进入方式。
【讨论】：
if 语句:(
单一退出点 - 所有其他条件都相同 - 使代码的可读性显着提高。 但有一个问题：流行的建筑
resulttype res;
if if if...
return res;
是假的，“res=”并不比“return”好多少。它有一个 return 语句，但函数实际结束的地方有多个。
如果您的函数具有多个返回（或“res=”），通常最好将其分解为具有单个退出点的几个较小的函数。
【讨论】：
我通常的策略是在函数末尾只有一个 return 语句，除非通过添加更多来大大降低代码的复杂性。事实上，我更喜欢 Eiffel，它通过没有 return 语句来强制执行唯一的 return 规则（只有一个自动创建的“result”变量来放入你的结果）。
在某些情况下，通过多次返回可以使代码比没有它们的明显版本更清晰。有人可能会争辩说，如果您的函数过于复杂而无法在没有多个 return 语句的情况下理解，则需要进行更多的返工，但有时在这些事情上务实是件好事。
【讨论】：
如果您最终得到多个回报，则您的代码可能有问题。否则我会同意，有时能够从子例程中的多个位置返回是件好事，尤其是当它使代码更清晰时。
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 }
}
}
这样写会更好
@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]
}
请注意，这只是一个简单的示例
【讨论】：
作为指导方针，我最后投票支持单次返回。这有助于常见的代码清理处理 ...例如，看看下面的代码...
void ProcessMyFile (char *szFileName)
{
FILE *fp = NULL;
char *pbyBuffer = NULL:
do {
fp = fopen (szFileName, "r");
if (NULL == fp) {
break;
}
pbyBuffer = malloc (__SOME__SIZE___);
if (NULL == pbyBuffer) {
break;
}
/*** Do some processing with file ***/
} while (0);
if (pbyBuffer) {
free (pbyBuffer);
}
if (fp) {
fclose (fp);
}
}
【讨论】：
这可能是一个不寻常的观点，但我认为任何认为应该支持多个返回语句的人都不必在仅支持 4 个硬件断点的微处理器上使用调试器。 ;-)
虽然“箭头代码”的问题是完全正确的，但在使用多个 return 语句时似乎会消失的一个问题是在您使用调试器的情况下。您没有方便的包罗万象的位置来放置断点以保证您将看到出口并因此看到返回条件。
【讨论】：
函数中的返回语句越多，该方法的复杂性就越高。如果您发现自己想知道是否有太多的 return 语句，您可能想问问自己该函数中是否有太多的代码行。
但是，一个/多个 return 语句没有任何问题。在某些语言中，它是一种比其他语言 (C) 更好的做法 (C++)。
【讨论】：