为什么 Javascript `if...else if` 不会以 `else` 结尾？答案

【问题标题】：Why would Javascript `if...else if` not end with an `else`?为什么 Javascript `if...else if` 不会以 `else` 结尾？
【发布时间】：2011-12-25 00:31:46
【问题描述】：

这是我正在使用的教程中的 JavaScript 代码的 sn-p。我不明白为什么它没有以最后的else 子句结尾；我认为这是一个规则。

var curScene = 0;

function changeScene(decision) {
  var message = "";

  if(curScene == 1) {
    message = " welcome";
  } else if (curScene == 2) {
    message = " this is scene two";
  } else if (curScene == 3) {
    message = " this is scene three";
  }

  document.getElementById("sceneimg").src = "scene" + curScene + ".png";

  if(message != ""){
    alert(message);
  }
}

【问题讨论】：

不，else 不是必须的。
据我所知，没有必要使用任何语言的 else。如果在 if 条件为 false 时没有什么特别的事情要做，那么也没有逻辑上的需要。这将是一个空块。
else 是if/else 块中的可选关键字。而且，您的教程代码的逻辑可能不需要else
else 用于需要全面处理任何未被评估为真实的事物的情况。我见过以else if 结尾的代码，然后给出一个必须满足的条件。这是一种仅在必须满足特定条件并且您不关心业务逻辑之外的条件时才实现代码分支的方法。

标签： javascript if-statement conditional

【解决方案1】：

与为什么你只能有一个 if 的原因相同：

if( /*condition*/ ) {
    //some code
}

//other stuff

【讨论】：

【解决方案2】：

是的，总是有一个 else 是 非常好 的习惯（与 if-elseif 一起使用时）。有时人们甚至会这样写：

if(curScene == 1) {
    message =" welcome";
else if (curScene == 2) {
    message = " this is scene two";
}
else if (curScene == 3) {
    message = " this is scene three";
} else {
    // empty.
}

告诉人们在else中确实无事可做。

【讨论】：

但不需要（这就是问题所在）
你能解释一下为什么你认为这是一个好习惯吗？我想不出它遇到的任何常见问题。
告诉检查你代码的人“我没有错过 else 部分，else 中确实无事可做”
当 curScene 由于代码或环境的其他部分发生任何变化而获得意外值时，它会捕获，就像“default”在“switch”中捕获意外条件一样（参见stackoverflow.com/questions/4649423/…）跨度>

【解决方案3】：

我认为它总是应该以“else”结尾？

else 块是可选的。你可以有if 没有else。

【讨论】：

我是这么想的，但我还没有看到任何官方文档。即使MDN's docs 总是有一个最终的 else 子句。你能提供一些参考资料吗？

【解决方案4】：

不需要，出于同样的原因，if 本身不需要else。

通常最好有一个，作为一种“包罗万象”的情况，但上面的代码可以写成：

switch(curScene) {
    case 1: message = " welcome"; break;
    case 2: message = " this is scene two"; break;
    case 3: message = " this is scene three"; break;
}

在上面的代码中，我还可以添加：

    default: message = " invalid curScene value"; break;

但这完全是可选的。这取决于curScene 变量的可靠性是否我个人会添加它。

【讨论】：

这是双重不必要的，因为鼓励使用最后一个 break 声明，但绝对没有用处。

【解决方案5】：

else 是 default case 的 if 语句。如果没有else，那么如果没有满足if 或else if 案例中的任何条件，那么if 语句将什么也不做。

通常最好有一个默认情况，但很多时候它不是必需的，因此被排除在代码之外。

在这种情况下，如果curScene 不是1, 2, 3，则将使用else 语句，但由于在其他情况下无需处理，因此编码器没有包含else .

【讨论】：

【解决方案6】：

考虑场景 3
场景 1： 布尔条件

if (condition) {}
else {}

将条件指定为 else if 将是多余的，而且代码的作用对读者来说非常明显。在这种情况下使用 else if 没有任何论据。

场景 2： 无限状态

这里我们感兴趣的是测试条件 A 和 B（等等），如果它们都不成立，我们可能对也可能不感兴趣：

if (conditionA) {}
else if (conditionB) {}
else {} // this might be missing as it is in your case

这里的重点是不存在有限数量的互斥状态，例如：条件A 可能是num % 2 == 0，条件B 可能是num % 3 == 0。

我认为在这里使用合理数量的分支是自然且可取的；如果分支变得太多，这可能表明对 OO 设计的一些明智使用将导致极大的可维护性改进。

场景 3： Finite states

这是前两种情况的中间立场：状态的数量是有限的，但多于两个。测试类枚举类型的值是典型示例：

if (var == CONSTANT_FOO) {}
else if (var == CONSTANT_BAR) {} // either this,
else {} // or this might be missing

在这种情况下，使用 switch 可能会更好，因为它会立即向读者传达状态数量是有限的，并强烈提示可能在哪里找到所有可能状态的列表（在此示例中，常量开始与 CONSTANT_)。我的个人标准是我要测试的状态数：如果只有一个（没有 else if），我将使用 if；否则，一个开关。无论如何，在这种情况下我不会写 else if。

将 else 添加为空的 catch-errors 块

这与上面的场景 #2 直接相关。除非可能的状态是有限的并且在编译时已知，否则您不能说“在任何其他情况下”意味着发生了错误。看到场景 #2 中的 switch 会感觉更自然，我觉得以这种方式使用 else 会产生不好的代码气味。

改为使用带有默认分支的开关。它将更清楚地传达您的意图：

switch(direction) {
    case 'up': break;
    case 'down': break;
    default: // put error handling here if you want
}

这可能有点冗长，但读者很清楚代码的预期功能。在我看来，一个空的 else 块在这里看起来不自然且令人费解。

【讨论】：

谢谢Wazzy，这解释了很多:-)
@Starkemp315 如果您认为它解释了很多，请接受答案

【解决方案7】：

将答案验证的 if 条件 if(answer==100) 更改为 if(answer===100) 现在工作正常...

【讨论】：

欢迎来到Stack Overflow。在这种情况下，提供的代码工作得很好——提问者只是问为什么else在那个例子中没有是必要的。

【解决方案8】：

没有 else 子句在语法上很好。 MDN Documentation 基本上第二个 if 成为 else 的主体，请参阅“如果嵌套正确缩进会是什么样子”部分。

至于这是否是不好的做法，我认为这取决于意图。如果没有明确定义最后的 else 子句，您最终可能会遇到一个错误，即您没有涵盖的条件出现。考虑一下：

if(myVariable > 0) {
   doSomething();
} else if(myVariable < 0) {
   doSomethingElse();
}

如果 myVariable 为 0，则不会发生任何事情。如果您只是浏览一下代码，将很难看出。我会说，如果您遇到这种模式，那将是代码异味，可能有问题，但可能没问题。

同样的逻辑总是可以用嵌套的 if 语句来表达。我会选择更具可读性的东西。

【讨论】：