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 comentarios. Deberías hacer más claro el código mismo, y luego usa comentarios de resumen.

* Marcadores en el código: Son los que se colocan a la izquierda en el código. Es una nota que el desarrollador deja para sí mismo a fin de indicar que el trabajo ahí aún no está terminado. Puede ser una instrucción sintácticamente incorrecta para que el compilador la detecte, o bien un conjunto específico de caracteres como un comentario que pueda ser localizado fácilmente sin interferir con la compilación.

* Resumen del código: Es un comentario de una o dos líneas que resumen un pequeño grupo de sentencias. Son más valiosos que los comentarios repetitivos debido a que pueden leerse más rápidamente que al código. Son particularmente útiles cuando alguien distinto al autor trata de modificar el código.

* Descriptivos del propósito del código: son los que intentan explicar la intención de una sección de código. Operan más a nivel del problema que a nivel de la solución. Por ejemplo:

/* Capture la información de la factura actual */

Comentar eficientemente

El comentar efectivamente no consume mucho tiempo. Los comentarios excesivos son tan malos como la existencia de pocos de ellos, por lo que lograr el equilibrio es importante.

Puede tomar mucho tiempo escribir comentarios por dos razones comunes. La primera, el estilo de comentarios puede consumir demasiado tiempo o ser tedioso –de hecho, un dolor de cabeza. Si cabe, busca un nuevo estilo. Un estilo que requiera mucho trabajo mantener es un dolor de cabeza: Si los comentarios son difíciles de cambiar, no se cambiarán: se volverán imprecisos y llevarán a confusión, lo cual es peor que no tener comentarios del todo.

La segunda razón, el comentar podría ser difícil debido a que las palabras para describir lo que el programa está haciendo no surgen fácilmente. Eso usualmente es una señal de que no se entiende bien lo que hace el programa. El tiempo que se invierte en “comentar” es en realidad tiempo invertido en comprender mejor el programa, lo cual es tiempo que necesita invertirse sin importar si lo comentas o no.

Integra comentarios en tu estilo de programación

El ir comentando el código a medida que se escribe tiene la ventaja de que se va introduciendo mientras más frescos se tienen los detalles de programación. Comentar al final, por el contrario, consume más tiempo puesto que se deben recordar los detalles y las sutiles suposiciones de la programación, o leer de nuevo el código para comprenderlo, antes de escribir los comentarios, haciendo que estos sean menos precisos.

Muchos argumentan que la programación requiere mucha concentración, la cual no debe interrumpirse ni siquiera para escribir comentarios. Para rebatir este argumento podemos decir que si el código requiere mucha concentración es una clara señal de que es complejo, pero una alternativa sería utilizar el algoritmo como punto de partida para la codificación e ir convirtiendo las frases en comentarios a medida que codificamos.

Si tu diseño es difícil de codificar, simplifícalo antes de empezar a preocuparte del código o los comentarios. Si usas el algoritmo o el seudocódigo para clarificar tus ideas, la codificación será directa y los comentarios

...