¿Por qué Javascript `if ... else if` no termina con` else`?

Aquí hay un fragmento de código JavaScript de un tutorial con el que estaba trabajando. No entiendo por qué no termina con una cláusula final else; Pensé que era una regla.¿Por qué Javascript `if ... else if` no termina con` 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); 
    } 
}

Fuente

2011-11-09 Starkemp315

No, no es obligatorio tener más con un if. –

Que yo sepa, no es necesario tener otra persona en ningún idioma. Si no hay nada especial que quiera hacer cuando la condición if es falsa, tampoco existe una necesidad lógica. Sería un bloque vacío. – Toast

'else' es una palabra clave opcional en el bloque' if/else'. Y, posible, que una lógica de su código de tutorial no requiera 'else' –

Por la misma razón que por la que se puede tener sólo un único caso:

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

//other stuff

Fuente

2011-11-09 05:03:41

-2

sí, siempre tienen una demás es MUY BUENO hábito (cuando se utiliza con si-elseif) . a veces las personas incluso pueden escribir esto:

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. 
}

para decirle a la gente que no hay nada que hacer en el resto.

Fuente

2011-11-09 05:03:59

pero ** no ** requerido (y esa era la pregunta) – Aziz

sí, técnicamente, es opcional. –

¿Puedes explicar por qué crees que es un buen hábito? No puedo pensar en ningún problema común que capte. –

Pensé que siempre se suponía que terminaría con un "else"?

Te has equivocado. El bloque else es opcional. Puede tener if sin else.

Fuente

2011-11-09 05:04:19 Thilo

Eso es lo que pensé, pero no he visto ninguna documentación oficial. Incluso [documentos de MDN] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/if...else) siempre tienen una cláusula else final. ¿Podría proporcionar algunas referencias? – chharvey

No tiene por qué, por la misma razón, un if en sí mismo no requiere un else.

Por lo general, es una buena idea tener uno, como una especie de "cajón de sastre" la situación, pero el código de arriba puede ser escrito como:

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

En el código anterior, que también podría añadir:

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

Pero es completamente opcional hacerlo. Depende de qué tan confiable es la variable curScene es si o no yo personalmente añadiría en.

Fuente

2011-11-09 05:04:43

Es doblemente innecesario ya que se recomienda la última declaración 'break', pero no sirve para nada. – puk

else es una default case por la declaración if. Si no hay else, entonces si no se cumple ninguna de las condiciones en los casos if o else if, la sentencia if no hará nada.

Por lo general, es una buena práctica tener un caso predeterminado, pero hay muchas veces en que no es necesario y, por lo tanto, se excluye del código.

En este caso, si el curScene era distinta 1, 2, 3 nada, entonces la else DECLARACIÓN se usaría, pero ya que no hay procesamiento por hacer en otros casos, el codificador no ha incluido una else.

Fuente

2011-11-09 05:04:44 Serdalis

Considerar 3 Escenario
Escenario 1:condición booleana

if (condition) {} 
else {}

especificando una condición como persona si sería redundante, y es muy obvio para el lector lo que hace el código. No hay argumento para usar else si en este caso.

Escenario 2:estados Infinite

Aquí estamos interesados en las pruebas para las condiciones A y B (y así sucesivamente), y que puede o no estar interesado en lo que sucede si ninguno de ellos tiene :

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

El punto importante aquí es que no hay un número finito de estados mutuamente excluyentes, por ejemplo: Estadoa podría ser num % 2 == 0 y conditionB podría ser num % 3 == 0.

Creo que es natural y deseable usar una cantidad razonable de ramas aquí; si las ramas se vuelven demasiadas, esto podría ser una indicación de que un uso juicioso del diseño OO resultaría en grandes mejoras de mantenimiento.

Escenario 3:Finite states

Este es el punto medio entre los dos primeros casos: el número de estados es finito, pero más de dos. Las pruebas para detectar los valores de un tipo de enumeración-como es el ejemplo arquetípico:

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

En tales casos utilizando un interruptor es probablemente mejor porque se comunica inmediatamente al lector que el número de estados es finito y le da un fuerte indicio en cuanto a dónde se puede encontrar una lista de todos los estados posibles (en este ejemplo, constantes que comienzan con CONSTANT_). Mi criterio personal es el número de estados contra los que estoy probando: si es solo uno (no hay más si) usaré un if; de lo contrario, un interruptor. En cualquier caso, no escribiré otro si en este escenario.

Añadiendo otra cosa que un vacío de captura-errors bloquean

Esto está directamente relacionado con el escenario # 2 anterior. A menos que los posibles estados sean finitos y conocidos en tiempo de compilación, no puede decir que "en cualquier otro caso" significa que ocurrió un error. Viendo como en el escenario n. ° 2, un cambio se sentiría más natural, creo que el uso de este modo tiene un mal olor a código.

Use un interruptor con una derivación predeterminada en su lugar. Será comunicar su intención mucho más claramente:

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

Esto podría ser un poco más detallado, pero es claro para el lector cómo se espera que el código para funcionar. En mi opinión, un bloque de más vacío parecería antinatural y desconcertante aquí.

Fuente

2011-11-09 05:12:00 Wazzzy

Gracias Wazzy, esto es explica mucho :-) – Starkemp315

@ Starkemp315 Por qué fui votado -1 entonces ... Decepcionante ... – Wazzzy

@ Starkemp315 Acepte la respuesta si cree que le explicó mucho – Wazzzy

-4

cambio de la condición if para la validación de respuesta si (respuesta == 100) a si (respuesta === 100) que está funcionando bien ahora ...

Fuente

2013-03-16 06:41:01 Nagendra

Bienvenido a [so]. En este caso, el código provisto funciona perfectamente bien - el que pregunta está preguntando por qué 'else' * no * es necesario en ese ejemplo. –

No tener una cláusula demás está bien sintácticamente. MDN Documentation Básicamente, el segundo si se convierte en el cuerpo del otro, consulte la sección sobre "cómo se vería si el anidamiento se sangrara adecuadamente".

En cuanto a si es una mala práctica, creo que eso depende de la intención. Al no definir explícitamente la cláusula final, puede terminar con un error donde una condición que no cubrió viene a través. Considere esto:

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

No pasa nada si myVariable es 0. Sería difícil ver si eran simplemente echando un vistazo a través del código.Diría que si te topas con este patrón, sería un olor a código, algo podría estar mal, pero podría estar bien.

La misma lógica siempre se puede expresar con sentencias if anidadas. Me gustaría ir con lo que sea más legible.

Fuente

2016-07-22 23:49:21 linuxdan

¿Por qué Javascript `if ... else if` no termina con` else`?

Respuesta

Cuestiones relacionadas