'if' 语句是否应该总是有一个 'else' 子句？ [关闭]答案

【问题标题】：Should 'if' statement always have an 'else' clause? [closed]'if' 语句是否应该总是有一个 'else' 子句？ [关闭]
【发布时间】：2009-11-22 23:21:45
【问题描述】：

这可能是一个宗教论点，但在我的工作中，是否所有 IF 语句都应包含 ELSE 子句的问题一直令人作呕 - 即使 ELSE 子句仅包含一条说明它“故意留空”的注释.

我听到了双方的争论： 'For' 阵营 - 确保代码实际上已经解决了条件是否需要 ELSE 子句 '反对'阵营 - 代码更难阅读，增加了太多噪音

我对任何其他观点感兴趣，因为我必须用一个双方都满意的答案来解决这场辩论。

感谢您的帮助。

顺便说一句：我确实在 StackOverflow 上搜索过这个问题的答案，但找不到。如果有，只需包含指向它的链接并关闭。谢谢。

【问题讨论】：

@Dave，并不是说开发人员无法解析 else；这是大多数开发人员不会期望它在那里，所以这是不必要的噪音。有点像在你不要求的时候在拿铁咖啡里加了肉桂。你仍然可以喝它；这只是一次不太愉快的经历。
你会建议switch语句总是有一个默认情况吗？
您使用什么语言？我已经这样做了一段时间，作为一个通用的“规则”，这个概念很愚蠢——这让我想知道是否有特殊情况。
如果这个问题不是什么玩笑，这可能是我听过最没用的“通用规则”了；否则 /* 故意留空 */.
参见 ISO/IEC TR 2477:2013 D.20.2，第二段。它既便宜又能防止错误。

标签： coding-style

【解决方案1】：

对我来说似乎是无用的打字......并且可能是造成混乱的原因。不需要就别放！

【讨论】：

更多打字 = 更多出错机会！
为每个条件语句编写一个else 块表明您已经考虑了“假设”，即使else 块是空的。在我看来，这对于安全/可靠性的原因很重要。
如果不对齐（以及代码的含义），可能会因意外按下“tab”键而被破坏。
else 如果丢失可能是个问题。例如，尝试在没有 else 的情况下使其工作 >>> l = [22, 13, 45, 50, 98, 69, 43, 44, 1] >>> [x+1 if x >= 45 else x+ 5 for x in l]（祝你好运）

【解决方案2】：

没有。如果您不需要在else 端运行任何代码，则不需要else 子句。

【讨论】：

【解决方案3】：

从这里的回答可以清楚地看出，没有人觉得需要一个未使用的 else。我从未听说过或读过这样的事情。摆在你面前的更重要的问题是与同事/开发人员打交道，他们以某种方式坚信这就是 If Then 的使用方式。

听起来你不是这种情况下的资深人士，所以你不能简单地命令它是这样的。我建议询问“其他空虚”的各方，以说明在一本关于开发的书（博客不计入）中建议了这样一个过程的位置。更好的是，在关于发展的 3 本书中。自 1982 年以来，我已经阅读了我所分享的跨编程语言的编程书籍，但我从未见过这样的建议。

这样你就不会告诉他们他们错了，他们可以亲自接受。相反，您愿意接受这样的职位，但希望看到一些文件。他们有责任找到证据。要么他们找到了它，要么他们只能争辩说，每一本编程书籍都是错误的，而只有他们是对的。

祝你好运。

【讨论】：

【解决方案4】：

黄金法则：如果它使您的代码更清晰、更易于理解，则将其放入，否则将其忽略。经验丰富的程序员将能够根据具体情况做出这些判断。

【讨论】：

我的一般经验法则是 3+ else if 得到一个可能为空的 else 块来向其他人展示我的逻辑。
@Woot4Moo：一个可能为空的 else 块如何向其他人展示你的逻辑？

【解决方案5】：

您是在谈论源自 Algol 的语言吗？

在 Lisp 中，我会说是的：每个 IF 都应该有一个 else 子句。否则，您应该使用 WHEN。

【讨论】：

【解决方案6】：

正如你所说，这可能是一个风格问题，但我不会仅仅因为“每个 if 块都应该有一个”而在我的代码中放入空的 else 块。在我看来，它只是在代码中增加了一些字符，并在代码审查期间多花一点时间（非常一点价值）。

【讨论】：

【解决方案7】：

需要else 很臭。需要时使用它。所有程序员都了解缺少else 的构造和含义。这就像一个与代码相呼应的毫无意义的评论。这简直是愚蠢的 IMO。

【讨论】：

【解决方案8】：

我倾向于使用“早期 if”语句来降低嵌套括号（或 Python 中的缩进）的级别，如下所示：

if (inParam == null) {
  return;
}

if (inParam.Value < 0) {
  throw new ArgumentException(...,...);
}
// Else ... from here on my if statements are simpler since I got here.

当然，.Net 4.0 现在有了代码合约，这很棒！但是，大多数语言还没有这个功能，所以“早期的 if”（因为缺乏更好的术语）非常棒，因为它们消除了许多 else 子句和嵌套的 if。我不认为在高级语言中有一个 else 子句是有益的……哎呀，即使在汇编中！这个想法是：如果你检查并没有跳转，那么条件是错误的，我们可以继续。对我来说合乎逻辑......

编辑： 也请查看这篇文章，了解为什么 else 子句没有太大帮助： http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html

【讨论】：

【解决方案9】：

"确保代码实际上已经解决了是否条件需要一个 ELSE 子句”

这并不比在每个方法中都需要一个 catch 子句来确保所有可能的异常都得到正确处理。

【讨论】：

【解决方案10】：

没有。守卫条件就是一个很好的例子。您可以将其余的方法逻辑嵌套在 else 子句中，但它很快就会变得很丑。

【讨论】：

【解决方案11】：

只有一个空行代码注释的“else”通常意味着开发人员仔细考虑了条件，并更好地了解在给定时间实际采用的执行路径。所有最近的编译器都将删除“else”和注释，因此您不会减慢软件的执行速度。

除非我没有正确阅读其他回复，否则看起来大多数人都反对在代码中声明他们的想法所花费的时间，并且宁愿这样做。

【讨论】：

我也开始喜欢这个主意了。不要盲目地将它们放在任何地方，但它肯定会使代码更具可读性，特别是对于稍长的 if 块。此外，它有助于清楚地表达意图。

【解决方案12】：

至少 SQL Server 2000、2005。

IF 1 = 1
BEGIN
    PRINT 'doing something productive'
END
ELSE
BEGIN
    --Just sitting here
END


Msg 102, Level 15, State 1, Line 8
Incorrect syntax near 'END'.

你必须有一个有意义的语句，这意味着一个虚拟的分配或返回数据给客户端。我想我可以使用 WAITFOR DELAY...

【讨论】：

【解决方案13】：

Haskell 的 if 总是三元的。所以 else 是强制性的。

【讨论】：

【解决方案14】：

if (thereIsSomeThingToDoInTheElse)
{
    putAnElseClause();
}
else
{
    // intentionally left blank
}

【讨论】：

shudder 调试起来会很有趣，当注释后的下一行被执行为“else”时，显然不是有意的
是的...我添加了大括号来修复它...谢谢
这个编辑可能是反对空 else 子句的主要原因之一
@Rado 这就是强制 else 语句的准则也强制大括号的原因。

【解决方案15】：

如果您的代码足够复杂以至于这成为一个问题，那么您可能应该重新考虑解决问题的方法。将你正在做的事情分解成更小的更简单的函数，在这些函数中，if 语句的作用应该非常明显。

如果您不能将其分解为更小的函数，或者您发现自己在另一个中嵌套了多个 if 语句，则将 if 语句用于您的条件逻辑可能不太适合。考虑开关、查找表（如果条件之间的唯一区别是某个常数的值）或决策表。

如果你已经完成了这一切，那么你就是在为一件如此令人难以置信的琐碎事情而争论不休，几乎不值得你花时间去争论。

【讨论】：

微不足道，是的。然而，当管理层决心强迫开发人员遵守此类标准时，即使是微不足道的（而且非常愚蠢的）也会成为关键决策。
在此类技术问题上抵御尖头老板的常见问题是工程师使用逻辑和推理。不幸的是，当一个人与迷信和权威作斗争时，这些永远不会成功。相反，用他们的观点来反对他们：问，“什么是商业案例？” “违背既定有效的行业标准实践如何使我们的产品成本更低或更有价值？”代码越多，错误的地方就越多，工程师的理解速度就越慢。

【解决方案16】：

这可能是一个好主意的少数可能情况之一是您有多个嵌套的if 语句，但else 子句较少。该语言将指定else 与哪个if 匹配，但读者可能并不总是清楚这一点。当然，将内容放在大括号中的地方，嵌套会很明显，所以没有歧义。这使得这有点人为的案例，但仍然可能值得一提。此外，如果您的代码如此复杂，可能还有更清晰的编写方式。

【讨论】：

我同意这里的最后一句话。任何需要这个的方法都太复杂了，应该重构。
这基本上就是我想要表达的观点。

【解决方案17】：

在某些情况下，在不需要时使用可选语法元素可以提高可读性或防止将来出现错误。一个典型的例子是单句条件句周围的括号：

在做

if(foo){
    bar
}

而不是

if(foo)
    bar

最终可以阻止

if(foo)
    bar
    dot

我真的想不出任何我知道的语言在哪里省略不必要的 else 会导致潜在的错误：-?

【讨论】：

【解决方案18】：

有很多“词”告诉你编程的方法比如DRY

在这种情况下，我会使用 YAGNI.. 你不需要它..

所以按照这个你不应该写 else。

无论如何，在我看来，它使阅读和理解代码变得更加困难......你写的越多，代码就越难理解

编辑：这是您要求的链接： http://en.wikipedia.org/wiki/YAGNI http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

【讨论】：

请链接或解释您的条款