Programación estructurada
[3] Siguiendo el teorema del programa estructurado, todos los programas se ven como compuestos de estructuras de control: Subrutinas son las unidades a las que se puede llamar, como procedimientos, funciones, métodos o subprogramas.
Se utilizan para permitir que una sola declaración haga referencia a una secuencia.
Señala que la combinación de las tres estructuras básicas, secuencia, selección e iteración, son suficientes para expresar cualquier función computable.
Esta observación no se originó con el movimiento de la programación estructurada.
En su escrito de 1974 «Programación estructurada con sentencias Goto», dio ejemplos donde creía que un salto directo conduce a código más claro y más eficiente sin sacrificar demostratividad.
[7] A este le siguieron numerosas objeciones, como una respuesta del propio Dijkstra que criticaba duramente a Rubin y las concesiones que otros autores hicieron cuando le respondieron.
Hay otras construcciones para manejar casos que son incómodos en la programación puramente estructurada.
Las excepciones también permiten la salida temprana, pero tienen consecuencias adicionales, y por lo tanto se tratan a continuación.
El problema más común en la salida anticipada es que las sentencias de limpieza o finales no se ejecutan - por ejemplo, la memoria asignada no se desasigna, o los archivos abiertos no se cierran, causando fugas de memorias o fugas de recursoss.
Esto debe hacerse en cada sitio de retorno, lo que es frágil y puede dar lugar fácilmente a errores.
Por ejemplo, en un desarrollo posterior, una sentencia return podría ser pasada por alto por un desarrollador, y una acción que debería realizarse al final de una subrutina (por ejemplo, una sentencia trace) podría no realizarse en todos los casos.
Los lenguajes sin sentencia return, como Pascal estándar y Seed7, no tienen este problema.
Ofrecen una solución tipo "recetario" para transformar una función que consiste solo en condicionales anidados en una secuencia de declaraciones de retorno (o lanzamiento) protegidas, seguida de un bloque sin protección, que está destinado a contener el código para el caso común, mientras que las declaraciones protegidas deben tratar con los casos menos comunes (o con errores).
Watt también señala que, aunque los secuenciadores de salto (gotoss) han sido algo restringidos en lenguajes como C, donde el objetivo debe estar dentro del bloque local o de un bloque exterior que lo envuelva, esa restricción por sí sola no es suficiente para hacer que la intención de los gotos en C sea auto-descriptiva y, por lo tanto, aún pueden producir "código espagueti".
