Programación estructurada

El teorema del programa estructurado proporciona la base teórica de la programación estructurada. Afirma que tres formas de combinar programas —secuenciación , selección e iteración— son suficientes para expresar cualquier función computable . Esta observación no se originó con el movimiento de programación estructurada; estas estructuras son suficientes para describir el ciclo de instrucciones de una unidad central de procesamiento , así como el funcionamiento de una máquina de Turing . Por lo tanto, un procesador siempre está ejecutando un "programa estructurado" en este sentido, incluso si las instrucciones que lee de la memoria no forman parte de un programa estructurado. Sin embargo, los autores suelen atribuir el resultado a un artículo de 1966 de Böhm y Jacopini, posiblemente porque Dijkstra citó este artículo él mismo. ^{[ 5 ]} El teorema del programa estructurado no aborda cómo escribir y analizar un programa estructurado útil. Estos temas se abordaron durante finales de la década de 1960 y principios de la de 1970, con importantes contribuciones de Dijkstra , Robert W. Floyd , Tony Hoare , Ole-Johan Dahl y David Gries .

PJ Plauger , uno de los primeros en adoptar la programación estructurada, describió su reacción ante el teorema de la programación estructurada:

Nosotros, los conversos, les mostramos esta interesante noticia a los programadores de lenguaje ensamblador recalcitrantes que seguían presentando intrincados fragmentos de lógica y diciendo: «Apuesto a que no pueden estructurar esto». Ni la demostración de Böhm y Jacopini ni nuestros repetidos éxitos al escribir código estructurado los convencieron antes de lo que estaban preparados para hacerlo. ^{[ 6 ]}

Donald Knuth aceptó el principio de que los programas deben escribirse teniendo en cuenta la demostrabilidad, pero no estuvo de acuerdo con la abolición de la instrucción GOTO, y a partir de 2018ha continuado usándolo en sus programas. ^{[ 7 ]} En su artículo de 1974, "Programación estructurada con instrucciones Goto", ^{[ 8 ]} dio ejemplos donde creía que un salto directo conduce a un código más claro y eficiente sin sacrificar la demostrabilidad. Knuth propuso una restricción estructural más flexible: debería ser posible dibujar el diagrama de flujo de un programa con todas las ramas hacia adelante a la izquierda, todas las ramas hacia atrás a la derecha y ninguna rama que se cruce entre sí. Algunos de los que conocen los compiladores y la teoría de grafos han defendido permitir solo grafos de flujo reducibles .

Los teóricos de la programación estructurada obtuvieron un importante aliado en la década de 1970 cuando el investigador de IBM, Harlan Mills, aplicó su interpretación de la teoría de la programación estructurada al desarrollo de un sistema de indexación para el archivo de investigación de The New York Times . El proyecto fue un gran éxito de ingeniería, y los directivos de otras empresas lo citaron para justificar la adopción de la programación estructurada, aunque Dijkstra criticó las diferencias entre la interpretación de Mills y el trabajo publicado. ^{[ 9 ]}

Todavía en 1987 era posible plantear la cuestión de la programación estructurada en una revista de informática. Frank Rubin lo hizo ese año con una carta abierta titulada "'GOTO' considerado perjudicial". ^{[ 10 ]} Le siguieron varias objeciones, incluida una respuesta de Dijkstra que criticó duramente tanto a Rubin como las concesiones que otros autores hicieron al responderle.

A finales del siglo XX, casi todos los informáticos estaban convencidos de la utilidad de aprender y aplicar los conceptos de programación estructurada. Lenguajes de programación de alto nivel que originalmente carecían de estructuras de programación, como FORTRAN , COBOL y BASIC , ahora las tienen.

La mayoría de los lenguajes de programación ofrecen una instrucción `return` que permite múltiples puntos de salida anticipada de una función . Dado que una función es un bloque, esta característica contradice el único punto de salida descrito en el teorema.

Muchos lenguajes permiten salir de un bloque de forma anticipada (sin usar `return`). Por ejemplo, un bucle puede admitir una instrucción `break` que finaliza el bucle antes de su conclusión. Como describe el teorema, esta lógica de salida anticipada puede eliminarse añadiendo bifurcaciones o comprobaciones, pero esto puede aumentar considerablemente la complejidad. C es un ejemplo temprano y destacado de estas construcciones. Algunos lenguajes más recientes también cuentan con "breaks etiquetados", que permiten salir de más bucles además del más interno.

La necesidad de múltiples salidas puede surgir por diversas razones, la mayoría de las veces porque la función ya no tiene trabajo que hacer (si devuelve un valor, significa que ha completado el cálculo) o porque ha encontrado circunstancias "excepcionales" que le impiden continuar, por lo que se necesita un manejo de excepciones.

Un problema con la salida anticipada es que las instrucciones de limpieza podrían no ejecutarse. Por ejemplo, la memoria asignada no se libera o los archivos abiertos no se cierran, lo que provoca fugas de memoria y de recursos . La limpieza debe realizarse en cada punto de retorno, lo que resulta engorroso y puede generar errores fácilmente. Por ejemplo, en una fase posterior del desarrollo, un desarrollador podría pasar por alto una instrucción de retorno, y una acción que debería realizarse al final de una función (por ejemplo, una instrucción de rastreo ) podría no ejecutarse en todos los casos. Los lenguajes sin instrucción de retorno, como Pascal , Lisp y OCaml , no presentan este problema.

La mayoría de los lenguajes modernos proporcionan soporte a nivel de lenguaje para prevenir tales fugas ^{[ 11 ]} (ver administración de recursos ). Como alternativa estructurada al uso de goto y un bloque de limpieza, la protección de desenrollado asegura que cierto código se ejecute cuando la ejecución sale de un bloque; a menudo se implementa en conexión con el manejo de excepciones como un try-finally. Un enfoque alternativo, en C++, es la adquisición de recursos en la inicialización , que utiliza el desenrollado normal de la pila (desasignación de variables) al salir de la función para llamar a los destructores en variables locales para desasignar recursos.

Kent Beck , Martin Fowler y sus coautores han argumentado en sus libros sobre refactorización que las condicionales anidadas pueden ser más difíciles de entender que cierto tipo de estructura más plana que utiliza múltiples salidas predicadas por cláusulas de guarda . Su libro de 2009 afirma rotundamente que "un único punto de salida no es una regla realmente útil. La claridad es el principio clave: si el método es más claro con un único punto de salida, utilice un único punto de salida; de lo contrario, no lo haga". Ofrecen una solución de libro de recetas para transformar una función que consta únicamente de condicionales anidadas en una secuencia de sentencias de retorno (o lanzamiento) protegidas, seguidas de un único bloque no protegido, que está destinado a contener el código para el caso común, mientras que las sentencias protegidas se supone que manejan los casos menos comunes (o con errores). ^{[ 12 ]} Herb Sutter y Andrei Alexandrescu también argumentan en su libro de consejos de C++ de 2004 que el único punto de salida es un requisito obsoleto. ^{[ 13 ]}

En su libro de texto de 2004, David Watt escribe que "los flujos de control de entrada única y salida múltiple suelen ser deseables". Utilizando el concepto de secuenciador del marco de Tennent , Watt describe uniformemente las estructuras de flujo de control presentes en los lenguajes de programación contemporáneos e intenta explicar por qué ciertos tipos de secuenciadores son preferibles a otros en el contexto de los flujos de control de salida múltiple. Watt escribe que los gotos sin restricciones (secuenciadores de salto) son malos porque el destino del salto no es autoexplicativo para el lector de un programa hasta que este encuentra y examina la etiqueta o dirección real que es el destino del salto. Por el contrario, Watt argumenta que la intención conceptual de un secuenciador de retorno es clara a partir de su propio contexto, sin necesidad de examinar su destino. Watt escribe que una clase de secuenciadores conocidos como secuenciadores de escape , definidos como un "secuenciador que termina la ejecución de un comando o procedimiento que lo contiene textualmente", abarca tanto las interrupciones de bucles (incluidas las interrupciones de varios niveles) como las sentencias de retorno. Watt también señala que, si bien los secuenciadores de salto (gotos) han estado algo restringidos en lenguajes como C, donde el destino debe estar dentro del bloque local o de un bloque externo que lo abarque, esa restricción por sí sola no es suficiente para que la intención de los gotos en C sea autodescriptiva y, por lo tanto, aún pueden producir " código espagueti ". Watt también examina cómo los secuenciadores de excepciones difieren de los secuenciadores de escape y de salto; esto se explica en la siguiente sección de este artículo. ^{[ 14 ]}

En contraste con lo anterior, Bertrand Meyer escribió en su libro de texto de 2009 que instrucciones como break y continue "son simplemente el viejo goto disfrazado de oveja" y desaconsejó encarecidamente su uso. ^{[ 15 ]}

Peter Ritchie señala que, en principio, incluso un único lanzamiento justo antes del retorno constituye una violación del principio de salida única, pero argumenta que las reglas de Dijkstra se escribieron en una época anterior a que el manejo de excepciones se convirtiera en un paradigma en los lenguajes de programación, por lo que propone permitir cualquier número de puntos de lanzamiento además de un único punto de retorno. Señala que las soluciones que encapsulan excepciones para crear una única salida tienen una mayor profundidad de anidamiento y, por lo tanto, son más difíciles de comprender, e incluso acusa a quienes proponen aplicar tales soluciones a lenguajes de programación que admiten excepciones de incurrir en un pensamiento de culto al cargo . ^{[ 16 ]}

David Watt también analiza el manejo de excepciones en el marco de los secuenciadores (introducidos en este artículo en la sección anterior sobre salidas anticipadas ). Watt señala que una situación anormal (generalmente ejemplificada con desbordamientos aritméticos o fallos de entrada/salida como archivo no encontrado) es un tipo de error que "se detecta en alguna unidad de programa de bajo nivel, pero [para la cual] un manejador se ubica de forma más natural en una unidad de programa de alto nivel". Por ejemplo, un programa podría contener varias llamadas para leer archivos, pero la acción a realizar cuando no se encuentra un archivo depende del significado (propósito) del archivo en cuestión para el programa y, por lo tanto, una rutina de manejo para esta situación anormal no puede ubicarse en el código del sistema de bajo nivel. Watts señala además que introducir pruebas de indicadores de estado en la función que realiza la llamada, como implicaría la programación estructurada de salida única o incluso los secuenciadores de retorno (de múltiples salidas), da como resultado una situación en la que "el código de la aplicación tiende a llenarse de pruebas de indicadores de estado" y que "el programador podría olvidar o descuidar la prueba de un indicador de estado. De hecho, las situaciones anormales representadas por indicadores de estado se ignoran por defecto". Señala que, a diferencia de las pruebas de indicadores de estado, las excepciones tienen el comportamiento por defecto opuesto , lo que provoca que el programa termine a menos que el programador gestione explícitamente la excepción de alguna manera, posiblemente añadiendo código para ignorarla deliberadamente. Basándose en estos argumentos, Watt concluye que los secuenciadores de salto o los secuenciadores de escape (discutidos en la sección anterior) no son tan adecuados como un secuenciador de excepciones dedicado con la semántica descrita anteriormente. ^{[ 17 ]}

El libro de texto de Louden y Lambert enfatiza que el manejo de excepciones difiere de las construcciones de programación estructurada como los bucles while porque la transferencia de control "se establece en un punto diferente del programa que aquel donde tiene lugar la transferencia real. En el punto donde realmente ocurre la transferencia, puede que no haya ninguna indicación sintáctica de que el control se transferirá de hecho". ^{[ 18 ]} El profesor de informática Arvind Kumar Bansal también señala que en los lenguajes que implementan el manejo de excepciones, incluso las estructuras de control como for, que tienen la propiedad de salida única en ausencia de excepciones, ya no la tienen en presencia de excepciones, porque una excepción puede causar prematuramente una salida temprana en cualquier parte de la estructura de control; por ejemplo, si init()lanza una excepción en for (init(); check(); increm()), entonces no se alcanza el punto de salida habitual después de check(). ^{[ 19 ]} Citando múltiples estudios previos de otros (1999-2004) y sus propios resultados, Westley Weimer y George Necula escribieron que un problema significativo con las excepciones es que "crean rutas de flujo de control ocultas que son difíciles de razonar para los programadores". ^{[ 20 ]}

La necesidad de limitar el código a puntos de salida únicos aparece en algunos entornos de programación contemporáneos centrados en la computación paralela , como OpenMP . Las diversas construcciones paralelas de OpenMP, como parallel do, no permiten la salida anticipada desde dentro hacia fuera de la construcción paralela; esta restricción incluye todo tipo de salidas, incluidas break y excepciones, pero todas estas están permitidas dentro de la construcción paralela si el destino del salto también está dentro. ^{[ 21 ]}

Con relativa poca frecuencia, las funciones permiten múltiples entradas. Lo más común es que esto se reinicie en una corrutina (o generador /semirrutina), donde una función cede el control (y posiblemente un valor), pero puede reanudarse donde se interrumpió. Existen varios usos comunes de este tipo de programación, especialmente para flujos (en particular, de entrada/salida), máquinas de estados y concurrencia. Desde el punto de vista de la ejecución del código, ceder el control desde una corrutina se asemeja más a la programación estructurada que regresar de una función, ya que la función no ha terminado realmente y continuará cuando se la vuelva a llamar; no se trata de una salida anticipada. Sin embargo, las corrutinas implican que múltiples funciones tengan un estado de ejecución, en lugar de una única pila de llamadas de funciones, lo que introduce una complejidad diferente.

Es raro que las funciones permitan el acceso a una posición arbitraria dentro de la función, ya que en este caso el estado del programa (como los valores de las variables) no está inicializado o es ambiguo, y esto es similar a un goto.

Algunos programas, en particular los analizadores sintácticos y los protocolos de comunicación , tienen varios estados que se suceden de una manera que no se reduce fácilmente a las estructuras básicas, y algunos programadores implementan los cambios de estado con un salto al nuevo estado. Este tipo de cambio de estado se usa frecuentemente en el núcleo de Linux. ^{[ 22 ]}

Sin embargo, es posible estructurar estos sistemas convirtiendo cada cambio de estado en una función independiente y utilizando una variable para indicar el estado activo (véase trampolín ). Alternativamente, pueden implementarse mediante corrutinas, que prescinden del trampolín.