Codificación aprenderaprogramar.com: CU00177A
MODIFICACIÓN DIRECTA DEL FLUJO DE PROGRAMAS
Hasta ahora hemos abordado la construcción de algoritmos a partir de tres tipos de estructura:
a) Estructura secuencial.
b) Estructura de decisión.
c) Estructura de repetición.
Existe un amplio consenso, y la experiencia de cualquier programador lo confirma, en relación a que éstas son las tres estructuras absolutamente necesarias para programar. Los programas, por muy largos y complejos que sean, se pueden construir combinando adecuadamente estas tres estructuras básicas. Si esto es así, podemos afirmar que con los conocimientos que tenemos estamos preparados para:
· Diseñar algoritmos eficientes.
· Desarrollar algoritmos largos.
· Desarrollar algoritmos complejos.
Y en buena medida esto es posible porque desarrollamos algoritmos con flujos muy ordenados, donde una instrucción se ejecuta a continuación de la anterior, donde los caminos dispersos siempre van confluyendo, donde las entradas, salidas y número de iteraciones en los bucles están muy bien controladas y donde existe un inicio, desarrollo y fin del programa. Todo ello nos lleva a:
· Programas claros para leerlos.
· Programas fáciles de entender.
· Programas fáciles de corregir.
· Programas eficientes en su funcionamiento.
Ahora nos preguntamos: ¿Existen otras posibilidades a la hora de desarrollar programas? (Posibilidades como que una instrucción no se ejecute a continuación de la otra, como que los caminos dispersos no confluyan, como poder salir de un bucle sin hacerlo por la vía normal, como que no exista un único fin sino varios, etc.)
La respuesta es que sí, esas posibilidades existen. Para bien o para mal, los ordenadores nos ofrecen mucha potencia y muchas posibilidades. Somos casi dioses. Cuando se utilizan estas herramientas que no obedecen a ninguna de las tres estructuras básicas, se habla de programación no estructurada, por contraposición a la programación estructurada
Hace ya varias décadas surgió un movimiento abanderado por estudiosos de la programación que pretendía establecer unas técnicas y disciplina que permitiera mejorar la calidad de los programas. Fue el nacimiento de la teoría de programación estructurada y de un proceso de cambio en los métodos y hábitos de programación. El origen de este movimiento puede buscarse en lenguajes o corrientes de programación que se estaban apoyando muy directamente en el control directo del flujo de los programas a través de saltos, decisiones de salida de bucles, etc. que hacían complicado determinar cuál era el flujo real del programa.
Una idea gráfica puede ser la siguiente:
 |
 |
El uso indiscriminado de instrucciones de modificación directa del flujo se comprobó que daba lugar a:
· Programas difíciles de leer.
· Programas difíciles de entender.
· Programas difíciles de corregir.
· Programas poco eficientes en su funcionamiento.
Y a partir de aquí surgió el debate: ¿Qué hacer con las instrucciones de modificación directa del flujo de programas? Teniendo en cuenta el tiempo que ha pasado ha habido respuestas de toda índole. Vamos a intentar resumirlas en tres posturas:
a) Prohibirlas: impedir que sea posible usarlas, eliminándolas del lenguaje.
b) Reducirlas: evitar a toda costa su uso limitándolo a aquellos casos en que son de gran utilidad.
c) Mantenerlas como igual de válidas: no estar a favor ni en contra de la reducción o eliminación de esas instrucciones, entendiendo que el responsable de un mal programa es el programador y no los medios que pueda tener a su disposición.
Con la perspectiva del tiempo y hablando de lo que es la situación en la actualidad, podemos decir que ha sido la posición de reducción al máximo del flujo no natural de programas la que se ha impuesto. Y que esto haya sido así tiene su lógica. Eliminarlas hubiera significado renunciar a instrumentos potentes que nos permiten resolver ciertas situaciones complicadas con sencillez. Son la varita mágica: si se usa bien puede convertir el plomo en oro, y si se usa mal puede convertirnos a nosotros mismos en un ratón (seguramente perdido en un laberinto además).
Seguir considerándolas como herramientas igual de válidas para construir programas apoyándose en ellas hubiera significado aceptar que eran igual de buenas que otras técnicas de programación, y esto no es así, como ha demostrado la programación estructurada. A modo de conclusión, propondremos:
1. Crear programas basados en estructuras secuenciales, de decisión y de repetición, con flujos naturales.
2. Evitar el uso de control directo de flujos (“saltos”).
3. En circunstancias concretas y no de forma habitual, apoyarnos en el control directo del flujo del programa.
¿A qué llamamos circunstancias concretas? Pues aquellas situaciones en las que el uso de instrucciones de control directo del flujo:
· Permitan salida a una situación difícilmente programable de otra manera.
· Introduzcan una gran claridad y facilidad de comprensión frente a otra opción.
· Permitan condensar una gran cantidad de código teniendo fácil lectura e interpretación.
Hemos hecho una pequeña introducción para las instrucciones que vamos a estudiar a continuación. Los motivos para ello han sido dos: por un lado, continuar con la línea que venimos manteniendo de reflexionar en torno a estrategias de aproximación a los problemas, aspecto más “filosófico” que técnico. Y por otro, evitar presentar estas instrucciones como si de unas más se trataran. Con todo lo expuesto, creemos que se parte de unas pautas útiles para hacer un buen uso de ellas.
La cantidad de instrucciones disponibles para el control directo de flujos es variable en función del lenguaje que se utilice. Vamos a estudiar, para la creación de pseudocódigo, las siguientes:
· Finalizar.
· SalirDesde.
· SalirMientras.
· SalirHacer.
· IrA.
Para acceder a la información general sobre este curso y al listado completo de entregas pulsa en este link: Ver curso completo.
Para hacer un comentario o consulta utiliza los foros aprenderaprogramar.com, abiertos a cualquier persona independientemente de su nivel de conocimiento.
