Eso pudo haber dicho Djikstra, el científico de cómputo que escribiese una nota de media cuartilla hace ya más de un cuarto de siglo, indicando que el uso de los GOTOs en los lenguajes de programación erz dañinos para la disciplina de la programación.
Y es que ahora un “bug” de seguridad en iOS parece deberse a un GOTO espurio. Sin embargo la lección parece ir más allá que el título del artículo de Djikstra: “Goto considered harmful”. La historia va así: Apple hace unos días hizo un parche a un error en la parte de criptografía de iOS, pero no indicó qué estaba parchando. Adam Langley, un experto en criptografía de Google, se metió a investigar qué habían hecho y encontró que todo parece ser un problema de un GOTO extra.
Y no es que no se pueda usar la instrucción GOTO, sino que esto provoca código poco estructurado, “espaguetti”, que hace que los programas sean menos legibles. Cuando se estructura el código en base a bloques Do-While, ciclo for, Repeat-until, es como usar -para hacer una analogía- usar bloques lego para armar una construcción de un juguete.
Langley piensa que el programador que hizo el parche copió y pegó parte del código. Parece que hizo la copia dos veces. Si el programador hubiese indentado el código aptopiadamentre, dice Langley, hubiese notado el problema de inmediato. Otra opción era usar la bandera “dead code” que aparece, por ejemplo, en GCC o CLang en Xcode, con lo cual se habría notado la dificultad (apareciendo un “warning”). En el fondo, el problema es querer llamar una función de error solamente una vez si se cumple cualquiera de las condiciones es verdadera, cuyo comportamiento puede cambiar con un GOTO. Langley piensa que cuando se trata de expresar condicionales, somos aún muy primitivos.
¿Quién hubiera pensado que un GOTO pudiese causar tantos problemas?
Referencias: