Question

一般来说，这是一种更好的做法，为什么？在什么情况下你会改变主意？

function foo1(int x) {
  int result;
  if (x > 5) {
    result = 2;
  } else {
    result = 7;
  }
  return result;
}

OR

function foo2(int x) {
  if (x > 5) {
    return 2;
  } else {
    return 7;
  }
}

Answer 1

第一个，因为它更容易记录和调试。

Answer 2

我更喜欢第二种形式，你马上回来。我所知道的唯一考虑因素如下。优点：

更短的代码
更容易关注
更少的变量（我猜是更容易理解的部分）

风险：

可以跳过返回后发生的清理处理

我不担心风险很大，因为如果您无意中将清理代码嵌套在某种条件块中，当您尝试管理保留返回值的各种执行路径时，风险类型仍然存在结束。我认为最好的办法是保持代码更简单，更容易遵循，以避免这种风险。我认为现代语言中的编码结构（例如“使用”和“尝试/最后”）也极大地帮助了风险。我现在总是尝试将它们用于清理任务，而不是简单地将代码放在块的末尾。

但是，当其他代码想要将挂起的返回值作为变量访问时（例如，将其添加到缓存中，以便下次可以更快地返回结果），我确实会例外。

Answer 3

我认为编写始终执行的代码会更好。例如，始终执行第一个示例中的return语句。我将分支保持在最低限度，因为无论你怎么努力，你的程序迟早会破坏。然后你会抓住你的头试图找出哪些if-branches在哪里执行，哪些不执行。为什么不避免这种情况，如果程序破裂很可能几乎是事实。：）

Answer 4

第一个，因为以下原因..

如“01”所述，易于记录和调试
易于重构

您的代码应始终采用此模式..

声明变量
初始化变量
处理
清理!!!!
返回

在这种模式中，其他人很容易理解你的代码行为，在哪里寻找问题，因为总是“Do Processing”是你的业务逻辑所在的部分，你当然可以重构第3步而不影响第4步和第五

如果你有机会看到大部分编码的“Windows COM / DCOM技术源代码”，他们总是有非常标准的使用retval结构的模式，只有使用标准模式，一个团队才能实现设计更大更好的系统，一个懒惰的程序员可以根据行数来编写最小的逻辑，但它对企业应用程序永远不会有好处。

我们在代码标准工具上花了很多钱，我们甚至经常需要编写更多代码，但在企业级别，标准实践和不太复杂的代码可以更好地维护和增长。

通过这样说，我同意即使在匆忙中我也不会多次按照完全相同的模式，但我也遇到了后果，当代码变大时，逻辑变得更复杂，逻辑重构变得困难。 / p>

为了编写更少的代码，我们使用重构，但不难理解复杂的逻辑。

即使您声明或未声明 retval，如果你有机会反汇编任何代码，你会看到该编译器总是声明一个内部变量用于无论如何都要回来。

Answer 5

我更喜欢第二种选择，因为它鼓励你一次只考虑一件事。

int MyFunction(...)
{
  if ( Simple case 1 )
    return 1;
  if ( Simple case 2 )
    return 2;

  ... evaluate complex cases ...
  return X;
}

如果简单案例1适用，您不必担心函数的其余部分。一旦你过去了，你就不必考虑如果应用简单案例1会发生什么。

这通常也会降低缩进程度，这往往会使事物更加线性且易于阅读。

Answer 6

或

function foo2(int x) {
  if (x > 5) {
    return 2;
  }
  return 7;
}

将结果存储在临时变量与多个返回点之间

6 个答案: