Question

在订购方面哪个更好？你把故障情况放在顶部还是底部？

if (noProblems == true) {
    // do stuff
} else {
    // deal with problem
}

OR

if (noProblems == false) {
    // deal with problem
} else {
    // do stuff
}

Answer 1

我想首先消除错误情况 - 并提前从函数返回，以便'幸福路径'保持不嵌套，例如

if (some error condition)
{
    //handle it
    return;
}
//implicit else for happy path
...

如果很容易识别导致幸福路径的条件，那么请务必先将该条款放入（感谢Marcin！）

Answer 2

这可能取决于语言惯例或其他因素，但我觉得名义案例应该在顶部，而分支应该包含特殊条件。它使代码更容易阅读。当存在许多异常情况时尤其如此，并且在大多数情况下存在。您将能够轻松地假设作者希望在大多数时间内使用此特定路径，并以这种方式更容易理解代码。

从“代码完成，第2版”第15.1节：

通过首先放置最常见的案例，您可以最大限度地减少必须阅读以查找常见案例的异常案例处理代码的数量。 您可以提高效率，因为您可以最大程度地减少代码执行的测试次数，以便找到最常见的案例。

Answer 3

如果它的1或2行和早期返回，我会把它放在顶部 - 特别是如果它在函数的开头。这几乎就像合同一样。否则，我选择“负面前的积极条件”规则。

Answer 4

这取决于你更清楚的事情。我的意思是，更有意义的是，没有问题具有真正的价值或者它具有错误价值。

例如对于isDeviceEnabled（），我总是会检查一个真实的结果，因为“Enabled”隐含了一个正值。对于隐式否定值，我们可以检查“isMemoryAvailable（）”的示例，可能是因为您只需检查新对象/数组或其他数据是否没有空间。

Answer 5

这是一个非常个人的决定，但我倾向于把我的错误条件放在首位，假装是将代码组合在一起。也就是说，如果我做了某些事情，并且失败了，那么对失败的检查实际上就是做某事的一部分;如果我根据代码的开头对检查失败和操作进行检查，我会将我的操作和对该操作的复杂响应分组在一起（假设失败结果实际上是一个更复杂的返回情况而不是成功）。

Answer 6

第一个似乎比我更好，因为它避免了条件中的双重否定。

除此之外，你已经构建了一些你不能真正

的东西

// do stuff

之后

// deal with problem

除此之外，它似乎和另一个一样好。

Answer 7

与 try / catch 一样，我执行正常流程，然后处理异常情况。

这并不意味着错误检查/清理不会首先发生，但如果我不相信传递给我的是什么。

如，

if (foo is null) then
    // bail
end if

if (bar == foo) then
    // foo hasn't been changed... print the regular report
else
    // foo has changed, run the reconciliation report instead.
end if

我喜欢这个快乐的故事像一条直线一样流动，而那个不愉快的故事则会转移到它自己的刺激上。

Answer 8

为什么不从函数创建一个退出点并在那里进行适当的清理而不是多次返回...


DWORD bRetVal= TRUE;
if(foo is null) 
{
   bRetVal = FALSE;
   goto Error;
}
else
{
// do something
}

Exit:
 return bRetVal;

编码风格......错误条件是第一个还是最后一个？

8 个答案: