2

我将其标记为 C，尽管它确实适用于许多语言。其原因是处理优化的问题的一部分，这取决于编译器。

有时我们在程序中会遇到这样的情况：

if(bob == 42)
{
    /* ... */
    return;
}
else
{
    /* ... */    
}

else正如您可能看到的那样，这里的块并不是绝对必要的。其他程序流控制结构也会发生同样的事情。由于特殊情况，一些“普通”结构变得多余。问题是：是否有理由编写这些冗余代码块？明晰？如果情况足够复杂，它能否帮助编译器进行优化？

4

4 回答 4

1

为了我自己，我经常写

if(bob == 42)
{
    /* ... */
    return;
}
/* else */

/* ... */

虽然我可能在这里遗漏了一些东西。

编辑：我也刚刚意识到这里的范围问题。至少在 C++ 中（不是在旧 C 中，不确定 C99 吗？） else 块会有它“自己”的不同范围，这可能值得注意。

于 2011-01-08T23:03:21.363 回答
1

我将您编写的内容称为“自记录代码”。通过使用 else 块，您可以让人们更容易看到如果 bob 不等于 42，则第二个代码块将被触发。

在我的计算机科学课上，我们会得到这样的代码示例来测试我们的逻辑能力。但在商业世界中，您真的不想让人们感到困惑或做任何可能减慢进度的事情。因此，假设性能影响可以忽略不计，您应该选择最容易阅读的内容。

自文档化代码意味着可以在函数名称中或通过阅读实际代码来看到正在发生的事情的解释，从而减少了对代码注释的需求。

就运行代码而言，用一些计时代码做一些测试，看看什么表现更好。

于 2011-01-08T23:09:17.760 回答
0

我通常对 if 语句使用以下注释结构：

/* Is bob 42 ? */
if(bob == 42)
{
  /* Bob is 42, return from function */

  return;
}
else
{
  /* Bob is not 42, do nothing */
}

编译器应该优化空的 else 子句。

于 2011-01-08T23:16:35.253 回答
0

我只喜欢一行（如果这与您的意思相同）

if (bob == 42) return;

这只是说明了它的作用，不需要额外的评论。相反，放入else一个块和注释和其他东西会使代码变得模糊，并分散对正在发生的事情的注意力，尤其是可能跟随的重要其他代码。

重复相同的消息而在注释中几乎没有修改会使代码的读者变得愚蠢。

如果这不是你的代码片段的意思，如果在这两种情况下真的有事情要做，我更喜欢

if (bob == 42) {
  /* do something if bob is the chosen one */
} else {
  /* for all others apply the standard treatment */ 
}
return;

这不会将您的 return 语句隐藏在一个块的深处。

总之，如果你觉得你必须评论你的流程控制而不是你的代码的语义，那么你做错了。

于 2011-01-09T09:52:50.680 回答