Guia Tecnica Para Programar

GUÍA DE TÉCNICAS PARA PROGRAMAR

Estructura de un programa

En la programación estructurada hay un inicio y un fin perfectamente bien definido de acuerdo al diagrama de flujo que se planteó al concebir la idea del programa.

Un programa bien estructurado debería tener algún subprograma que capture cualquier error dentro del programa principal o de cualquier subprograma dentro de la aplicación de tal modo que el subprograma que captura los errores genere un registro de datos que describa el error generado y/o en qué subprograma se generó el error para posteriormente corregirlo. Para facilitar la corrección de estos errores se hace uso de los comentarios agregados en el código fuente.

Variables y constantes

Como hemos visto, el ordenador sigue una serie de instrucciones. Pero esas instrucciones tienen que operar sobre una serie de datos. El ordenador típico sólo procesa una instrucción a la vez, por lo que necesita 'espacios de memoria' donde guardar o depositar, a modo de cajones, por usar un símil conocido, los diversos datos con los que trabaja. Aquí es donde entran en juego las variables y constantes.

En los inicios, con el ensamblador, se podía decir al ordenador, por ejemplo: 'Ejecuta la instrucción de esa posición de memoria' o también 'En esa posición de memoria está guardada mi edad, imprímela por pantalla'. Todo esto se deriva del hecho de que los programas también son datos. Esta ambigüedad presenta numerosos inconvenientes cuando se producen errores, como el lector se imaginará fácilmente: de ahí que, a medida que los lenguajes promocionan hacia niveles superiores, se impida el tratamiento indistinto de los datos. A partir de entonces, un programa tiene que decirle al sistema operativo los cajones que necesita y éste se los proporciona independientemente de cuáles sean.

Como cabe pensar, un procesador no tiene la instrucción "Imprime por pantalla"; esto es una llamada a otra porción de código que, gracias a la abstracción, nosotros no hemos escrito, o hemos escrito una sola vez; a partir de lo cual podemos imprimir todo el texto que queramos en la pantalla.

Si queremos leerlas o escribirlas, podemos hacerlo. Típicamente, existirán datos que no pensamos modificar; no querremos que el usuario tenga que introducirlos cada vez, pues son de naturaleza más constante que otros (como puede ser el valor Pi para calcular el perímetro o área de un círculo). Para evitar modificarlos por error, podemos pedir al sistema variables especiales, que no puedan ser reescritas. Son las Constantes.

Un ejemplo:

Comentario: Este programa calcula el área de un círculo

Constante PI = 3'14159265

Variable R

Variable Resultado;

Leer número y guardar en R

Calcular PI * (R * R) y guardar en Resultado

Imprimir Resultado;

El uso de variables y constantes se asemeja al uso que se les da en el álgebra o en otras ramas matemáticas.

Nótese también la clara separación entre estructuras de datos y algoritmos. Según los lenguajes, esto puede ser o no obligatorio, pero es recomendable en aras de una mayor claridad del trabajo.

Comentarios

El útil concepto del comentario: son líneas de texto que el compilador o el intérprete no consideran como parte del código, con lo cual no están sujetas a restricciones de sintaxis y sirven para aclarar partes de código en posteriores lecturas y, en general, para anotar cualquier cosa que el programador considere oportuno.

Uno como programador debe tener como prioridad documentar nuestro código fuente ya que al momento de depurar nos ahorrará mucho tiempo de análisis para su corrección o estudio.

Los programadores profesionales tienen la buena costumbre de documentar sus programas con encabezados de texto (encabezados de comentarios) en donde describen la función que va a realizar dicho programa, la fecha de creación, el nombre del autor y en algunos casos las fechas de revisión y el nombre del revisor.

Por lo general algunos programas requieren hacer uso de llamadas a subprogramas dentro de una misma aplicación por lo que cada subprograma debería estar documentado, describiendo la función que realizan cada uno de estos subprogramas dentro de la aplicación.

El estilo de programación como documentación

El principal contribuyente de la documentación a nivel de código no son los comentarios, sino el buen estilo de programación, el cual incluye una buena estructura de programa, el uso de un acercamiento directo y fácilmente comprensible, buenos nombres de variables y de rutinas, uso de constantes nombradas en lugar de valores literales, un esquema claro y la minimización de la complejidad del control de flujo y de las estructuras de datos.

El código de los programas escritos con un estilo pobre de programación casi siempre es críptico. Aun cuando se le trate de explicar usando comentarios, su calidad no se ve mejorada: permanece oscuro, difícil de leer y de modificar. La única manera de clarificarlo es rescribiéndolo usando un mejor estilo de programación. De este modo el código será más legible, aún si no posee comentarios que lo expliquen. El código que es legible por sí solo se denomina código autodocumentado, y es una característica deseable para cualquier programa de software. Tal código descansa en el buen estilo de programación utilizado en su creación para sobrellevar la mayor parte de la documentación interna. En un código bien escrito, los comentarios son piezas de información realmente necesarias que complementan la legibilidad y no una carga extra que, aunque de utilidad, hace que se incremente el tamaño del código fuente.

Tipos de comentarios

* Repetitivos del código: Replantean lo que el código dice en lenguaje común. Meramente dan al lector más que leer sin agregar información adicional de valor.

* Explicativos del código: Son usados típicamente para explicar piezas de código complicadas, truculentas, o sensibles. En tales situaciones son útiles, pero únicamente debido a que el código es confuso. Si el código es tan complicado que necesita ser explicado, casi siempre es preferible mejorar el código que añadir

...