¿Cuáles son ejemplos de problemas de la vida real debido a la falta de llaves en el software?

Por lo general, como primera tarea de codificación, estos corchetes no son realmente necesarios. Pero en cada proyecto no trivial siempre tendrá algunas modificaciones en una etapa posterior. No hay forma de evitar esto, sucederá. Y no es posible planificar cada uno de los futuros desarrollos, por lo que es mejor planificar el cambio.

Para explicar: cuando haya escrito su código sin llaves, agregar algo más tarde significa que también debe tener cuidado de agregar las llaves. Y dado que los humanos ven y leen usando una forma de “lógica difusa” (es decir, no “leemos” cada letra y signo de puntuación), es muy fácil pasar por alto estas cosas. Por lo tanto, para evitar tales errores “difusos” en el futuro, simplemente agregue las llaves incluso en las líneas de pedido individuales (vamos, son solo 2 pulsaciones de teclas, no más de un segundo extra).

Como muestra el ejemplo de Toby, el error más reciente comúnmente conocido de este tipo fue el error de error Goto de Apple. Y eso sucedió exactamente porque algún cambio posterior agregó una declaración goto sin agregar las llaves necesarias para agrupar el código lógicamente. Si las llaves estuvieran allí antes de la edición, la posibilidad de que esto ocurriera hubiera sido mucho menor. El problema con el ejemplo de error de goto es que el goto en sí mismo ya es peligroso y podría restarle importancia al problema “real” de la falla de agrupación de código.

Otro gran problema es al entrar en ifs anidados:

if (a) if (b) c(); else d(); 

¿Ves el problema allí? El código no se ejecutará ya que la sangría está tratando de mostrarse. La única forma de hacer cumplir esto es agregar llaves al menos a la primera cláusula if de la declaración. Entonces, ¿qué sucede cuando luego agrega un anidado si? De nuevo, esto significa que debe volver a leer el código para asegurarse de agruparlo correctamente (sin tener en cuenta ninguna sangría durante la lectura, ya que podría no significar nada en absoluto).

Recuerde también que en Java y Scala, las llaves abren un nuevo ámbito léxico contenido. Esto también podría funcionar para liberar variables definidas dentro de ese alcance. P.ej
¿Utiliza llaves para rítmica adicional?

Un antiguo ejemplo, una de las primeras pruebas de Mercury salió de curso porque el programa que calculaba la trayectoria tenía estas líneas, con la intención de ser un ciclo “for”:

  DO 5 I=1,3 VEL( I ) = ACC( I ) * MASS( I ) 5 CONTINUE 

Desafortunadamente, la primera línea tenía un punto en lugar de una coma, lo que convirtió el código en:

  DO5I = 1.3 VEL(I) = ACC(I) * MASS(I) 5 CONTINUE 

Entonces, no hay bucle. Solo VEL (I) fue recalculado, no VEL (1..3)

Esta fue una lección sobre cómo no debe diseñar lenguajes donde un error de un solo carácter puede pasar y hacer algo completamente diferente.

Podría decirse que se equivocó. Comprensión de Apple ‘goto fail’ Vulnerabilidad – Cigital

Pero en un nivel más mundano, sí, esta es una práctica arriesgada, y muchas guías de estilo lo prohíben. C también es un lenguaje terriblemente inseguro. Hay idiomas que no permiten este tipo de error.

El ejemplo directo es, por supuesto, la salida de depuración.

Usted escribe:

  si (x == 5)
     hacer algo();

La cosa no sucede y no hay nada de malo en la función llamada, por lo que te preguntas si el código se está activando en absoluto. Entonces, lo cambias a:

  si (x == 5)
     hacer algo();
     printf ("Tengo que hacer algo () \ n");

Y parece que está sucediendo mucho .

¿Puedo señalar un incidente conocido donde esto ha sucedido? No. Pero creo que es seguro decir que la mayoría de nosotros hemos hecho algo así al menos una vez.

¿Quieres hacer esto más aterrador? Ponga la condición en un bucle y decida que tal vez quiera salir del bucle con break; cuando es verdad

Sin embargo, aquí está el problema central: los estudiantes nunca creerán que cometerán estos errores. Los has señalado. Ahora está guardado en su memoria y siempre los estarán buscando … hasta que suceda y se pregunten por qué nadie les advirtió que siempre se pongan los frenos …