Por el bien de mi discusión, un Bool puede tener 2 estados, Verdadero o Falso. Cualquier otra cosa no es conforme con las especificaciones de programación langugae. Si la cadena de su herramienta no es conforme con su especificación, usted será elegido sin importar lo que haga.
Si un desarrollador creó un tipo de Bool que tenía más de 2 estados, es lo último que haría en mi código base.
Opción A.
if (var == true) {
...
} else if (var == false) {
...
} else {
...
}
Opción B
if (var == true) {
...
} else {
...
}
Afirmo que la Opción B es más robusta .....
Cualquier twit puede decirte que manejes errores inesperados. Usualmente son fáciles de detectar una vez que piensas en ellos. El ejemplo que ha dado su profesor no es algo que pueda ocurrir, por lo que es un ejemplo muy malo.
A es imposible de probar sin arneses de prueba complicados. Si no puedes crearlo, ¿cómo lo vas a probar? Si no has probado el código, ¿cómo sabes que funciona? Si no sabe que funciona, entonces no está escribiendo software robusto. Creo que todavía lo llaman un Catch22 (gran película, verlo en algún momento).
La opción B es trivial de probar.
Próximo problema, pregúntale al profesor esta pregunta "¿Qué quieres que haga al respecto si un booleano no es Verdadero ni Falso?"
Eso debería llevar a una discusión muy interesante ...
En la mayoría de los casos, un volcado de memoria es adecuado, en el peor de los casos, molesta al usuario o cuesta mucho dinero. ¿Qué pasa si, por ejemplo, el módulo es el sistema de cálculo de reingreso en tiempo real del transbordador espacial? Cualquier respuesta, no importa cuán inexacta, no puede ser peor que abortar, lo que matará a los usuarios. Entonces, qué hacer, si sabe que la respuesta podría estar equivocada, vaya por el 50/50, o cancele y vaya por la falla del 100%. Si yo fuera un miembro de la tripulación, me llevaría el 50/50.
La opción A me mata
La opción B me da una oportunidad uniforme de supervivencia.
Pero espera, es una simulación de la reentrada del transbordador espacial, ¿y luego qué? Abortar para que lo sepas. ¿Suena como una buena idea? - NO - porque necesita probar el código que planea enviar.
La opción A es mejor para la simulación, pero no se puede implementar. Es inutil
La opción B es el código desplegado, por lo que la simulación se realiza de la misma manera que los sistemas en vivo.
Digamos que esto era una preocupación válida. La mejor solución sería aislar el manejo de errores de la lógica de la aplicación.
if (var != true || var != false) {
errorReport("Hell just froze over, var must be true or false")
}
......
if (var == true){
....
} else {
....
}
Lecturas futuras : máquina Therac-25 Xray, falla del Ariane 5 Rocket y otros
(El enlace tiene muchos enlaces rotos pero suficiente información que Google ayudará)