GOTO: el salto que nos enseñó a caminar (¡el villano necesario!)
Imagina que estás leyendo una novela y, al final de cada página, una nota te dice: “continúa en la página 212”. Allí, otra nota te manda a la 57, y de ahí a la 340. Al cabo de diez saltos ya no recuerdas quién es el protagonista ni por qué huye. Así se sentían muchos programadores de los años sesenta frente a su propio código, y de esa sensación nació una de las revoluciones más importantes de nuestra disciplina.
📘 En este artículo vas a aprender- Qué hace exactamente la instrucción GOTO y por qué se volvió polémica.
- Qué es el «código espagueti» y cómo nació la programación estructurada.
- Quiénes fueron Böhm, Jacopini y Dijkstra, y qué demostraron.
- Dónde sigue viviendo el GOTO en los lenguajes que usas hoy.
Un salto sin red
Empecemos por lo básico. La instrucción GOTO transfiere el control del programa a otro punto del código, señalado por una etiqueta. Es un salto incondicional: no pregunta ni evalúa nada, simplemente ordena “vete allá” y la ejecución obedece.
En los primeros lenguajes, esa era casi la única forma de alterar el flujo del programa. Quien programó en las primeras versiones de BASIC recordará las líneas numeradas de 10 en 10 y el infaltable GOTO 10 para repetir algo. Funcionaba, y mientras los programas eran pequeños, hasta parecía elegante. El problema llegó cuando crecieron.
Mira cómo se contaba del 1 al 5 en aquella época:BASIC con GOTO
10 LET I = 1 20 IF I > 5 THEN GOTO 60 30 PRINT I 40 LET I = I + 1 50 GOTO 20 60 ENDVersión estructurada (Python)
for i in range(1, 6):
print(i)El nacimiento del código espagueti
Cuando un programa está plagado de saltos, para saber en qué estado se encuentra una variable hay que reconstruir mentalmente todos los caminos por los que se pudo llegar a ese punto. Con tres saltos es un ejercicio de paciencia. Con trescientos es una pesadilla. A ese enredo se le bautizó con un nombre muy gráfico: código espagueti. Tiras de un hilo para entender una parte y se mueve todo el plato.
Las consecuencias eran muy concretas: programas difíciles de seguir, casi imposibles de mantener y propensos a errores que aparecían en los lugares más inesperados. El software se estaba volviendo demasiado importante para seguir construyéndose así.
Los años sesenta: la rebelión ordenada
En esa década nació lo que hoy llamamos programación estructurada(**). Su propuesta era sorprendentemente sencilla: para escribir cualquier programa bastan las subrutinas y tres estructuras de control: secuencia (haz esto, luego esto), selección (si ocurre tal cosa, haz esto; si no, aquello) e iteración (repite mientras se cumpla una condición).
Esta idea tuvo un respaldo teórico sólido gracias al trabajo de Corrado Böhm y Giuseppe Jacopini, cuyo resultado (el teorema del programa estructurado) demostró que no necesitamos el salto incondicional para expresar cualquier algoritmo. Nada de lo que puedas escribir con GOTO es imposible de escribir sin él.
Y entonces llegó el golpe de efecto. En 1968, el neerlandés Edsger Dijkstra publicó su célebre escrito «La sentencia goto, considerada perjudicial». Su argumento central era que la calidad de un programador es inversamente proporcional a la cantidad de GOTO que usa, porque cada salto dificulta entender qué hace el programa a partir de su texto.
🔎 Dato curioso
Según se cuenta, el título provocador no lo eligió Dijkstra, sino el editor de la revista, Niklaus Wirth (sí, el mismo creador de Pascal). Desde entonces, la fórmula «… considerado perjudicial» se ha copiado cientos de veces en artículos de informática.La teoría se encontró con la práctica. Lenguajes como ALGOL llegaron con estructuras de control consistentes y bien formadas, demostrando que se podía programar con claridad sin recurrir al salto. La estructura dejó de ser una disciplina impuesta y pasó a ser el camino natural.
<¿Murió GOTO? Más bien se reencarnó
Aquí viene la parte que casi nadie cuenta. GOTO no desapareció: se disfrazó y se le puso un campo de acción delimitado. Cuando usas break para salir de un ciclo, continue para saltar a la siguiente vuelta o return para abandonar una función a mitad de camino, estás haciendo, en el fondo, un salto. Lo mismo ocurre con las excepciones y su try/catch. La diferencia es que ahora el salto tiene reglas, un alcance limitado y un nombre que anuncia su intención. Es el mismo animal, pero con correa.
Algunos lenguajes conservan el GOTO tal cual. C lo mantiene, y no es raro verlo en código de sistemas para liberar recursos ordenadamente cuando algo falla a mitad de una función:
int procesar(const char *ruta) {
FILE *f = fopen(ruta, "r");
if (!f) return -1;
char *buf = malloc(1024);
if (!buf) goto cerrar_archivo;
if (fread(buf, 1, 1024, f) == 0) goto liberar_memoria;
/* ... trabajo con los datos ... */
free(buf);
fclose(f);
return 0;
liberar_memoria:
free(buf);
cerrar_archivo:
fclose(f);
return -1;
}Fíjate en que aquí los saltos son siempre hacia adelante, hacia un bloque de limpieza al final. Ese patrón es predecible y fácil de leer; es el tipo de uso que incluso los críticos más duros del GOTO suelen aceptar. Otros lenguajes lo ofrecen con restricciones. Java, por ejemplo, reserva la palabra goto pero nunca le dio funcionalidad, y Python directamente prescinde de él.
⚖️ ¿Entonces GOTO es el demonio?
No tanto. El consenso moderno es más maduro: es una herramienta de uso muy específico, y quien la emplee debe tener una razón sólida y comunicarla bien. Hasta Donald Knuth, uno de los grandes nombres de la informática, escribió en 1974 defendiendo que en ciertos casos un uso razonado del salto puede ser legítimo.
Lo que esta historia nos enseña
Me gusta contar este episodio en clase porque va más allá de una instrucción. Nos muestra cómo evoluciona nuestra disciplina: alguien identifica un dolor real (el código ilegible), propone una restricción (menos libertad, más claridad) y la comunidad, con teoría y práctica, la adopta. Perdimos un poco de libertad y ganamos algo mucho más valioso: poder entender lo que escribimos hoy y lo que escribió otra persona hace cinco años.
La próxima vez que escribas un break sin pensarlo, dedícale un guiño al viejo GOTO. Fue el chivo expiatorio que nos obligó a pensar en el orden, pero también el maestro involuntario que nos enseñó que programar no es solo lograr que la máquina funcione, sino que otro ser humano pueda leerlo.
Ponte a prueba:
Responde primero por tu cuenta y luego despliega la respuesta.
1. ¿Qué tres estructuras de control bastan, según la programación estructurada?
Secuencia, selección e iteración (apoyadas en subrutinas).
2. ¿Por qué el GOTO genera «código espagueti»?
Porque los saltos entrelazan los caminos de ejecución: para saber cómo se llegó a una línea hay que reconstruir mentalmente todos los recorridos posibles, y eso vuelve el programa difícil de seguir, mantener y depurar.
3. Menciona dos instrucciones modernas que son «saltos con correa».
Por ejemplo break, continue, return o el manejo de excepciones con try/catch.
Reto: reescribe sin GOTO el ejemplo de BASIC pero contando de 10 a 1.
En Python: for i in range(10, 0, -1): print(i). Prueba ahora hacerlo en el lenguaje que estés estudiando.
.png)
