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

Question

这是我正在使用的教程中的一段 JavaScript 代码。 我不明白为什么它不以最后的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);
  }
}

Answer 1

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

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

Answer 2

出于相同的原因，如果您可以只有一个：

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

//other stuff

Answer 3

考虑 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

这里的重点是没有有限数量的互斥状态，例如：conditionA 可能是num % 2 == 0而 conditionB 可能是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_ 开头） . 我的个人标准是我要测试的状态数：如果只有一个（没有其他 if），我将使用 if； 否则，一个开关。 无论如何，在这种情况下我不会写 else if 。

添加 else 作为一个空的 catch-error 块

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

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

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

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

Answer 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变量的可靠性。

Answer 5

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

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

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

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

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

Answer 6

else是if语句的default case 。 如果没有else那么如果没有在该条件下if还是else if案件符合比if statment不会做任何事情。

通常有一个默认情况是一种很好的做法，但很多时候它是没有必要的，因此被排除在代码之外。

在这种情况下，如果curScene不是1, 2, 3那么将使用else语句，但由于没有对其他情况进行处理，编码器没有包含else 。

Answer 7

是的，总是有一个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 中确实无事可做。

Answer 8

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