Departamento de Estadística, I. O. y Computación
Universidad de La Laguna






Documentación de Programas

Introducción

    Quizás algún día los ordenadores sean capaces de escribir programas de ordenador para otras máquinas, o tal vez podamos escribir los programas en castellano, pero hasta que llegue ese momento hemos de conformarnos con escribir programas que otras personas han de leer. Casi nadie tendrá nada que objetar al hecho de que cualquier programador ha de escribir programas que al menos ella o él mismo sean capaces de leer. Aquí es donde la documentación de programas entra en escena. El estilo de programación tiene que ver con la legibilidad de los programas. Si cada programador utilizara un estilo individual y propio, los programas podrían ser incomprensibles para otros programadores, de modo que nuestro propósito será seleccionar (por convenio) y aplicar una serie de hábitos o técnicas de programación que han sido propuestos por programadores experimentados, tomando como fundamento el hecho de que tales hábitos conducen con mayor facilidad a programas que son correctos, eficientes, legibles y fácilmente modificables. Las reglas de estilo que presentaremos son el resultado del consenso entre programadores con experiencia. Una vez que nos acostumbremos a un cierto estilo, nuestros propios programas u otros escritos siguiendo estas reglas nos resultarán más fáciles de leer y modificar.
    Un buen programador debería codificar aprovechando toda posibilidad que asegure que su código es claro y fácil de comprender. No debe utilizar trucos inteligentes a los cuales los lenguajes de programación se prestan con facilidad. Considérese a modo de ejemplo los fragmentos de código de la Figura 1. Aunque la segunda versión del código (escrito en C) es más larga, también es más clara y fácil de comprender. Incluso un programador sin demasiada experiencia en C puede entender que la segunda parte del código tiene algo que ver con el movimiento de datos desde un punto fuente hacia un destino. Al compilador no le importa cuál de las dos versiones se utilice: un buen compilador generará exactamente el mismo código máquina para ambas. De hecho, si todo el código se coloca en una sola línea, sin utilizar retornos de carro, al compilador "le da igual", es siempre el programador (y solamente él) quien se beneficia de la claridad del código, aunque erróneamente los programadores sin experiencia tienden a pensar que "retorcido y complicado es equivalente a eficiente".     En este documento pretendemos presentar una serie de recomendaciones a la hora de codificar programas, cuya utilización puede contribuir a la claridad del código que se desarrolle.
    Todo programador tiene sus propios criterios acerca de cuáles son los mejores puntos para colocar documentación en el código fuente y sobre la mejor forma de hacerlo. El estilo correcto de docuemtación depende del lenguaje de programación y de las prácticas de la entidad para la que se desarrolle el software y quienes hayan de mantenerlo.
    Dado que no es nuestro propósito un listado exhaustivo y detallado de recomendaciones, hemos decidido que el documento sea breve, para facilitar así su completa lectura por quienes estén interesados en el tema (y todos los que desarrollamos software deberíamos estarlo) y para concentrarnos en las características más generales de la documentación de código.
    Las referencias bibliográficas que se encuentran al final de este documento pueden ser un buen punto de partida para quienes deseen ampliar el nivel de detalle aquí presentado.
    En concreto:

Comentarios

Distinguiremos tres tipos de comentario:     Es una buena idea que los comentarios de tipo bloque vayan delimitados por algún tipo de caracteres que los hagan claramente visibles. Por ejemplo, para Pascal:
(*********************************************************************************************************
*    Los comentarios de tipo bloque contienen texto en lenguaje natural escrito
*    en castellano o inglés correcto (hay que colocar tildes allí donde sea necesario,
*    y por supuesto, evitar las faltas de ortografía) y constan generalmente de varias líneas.
*
*    Generalmente ayuda a su legibilidad el dejar líneas en blanco entre cada uno de los
*    párrafos del comentario.
*
*    Este tipo de comentarios son especialmente idóneos para los comentarios prólogo o de directorio,
*    mientras que para comentarios explicatorios deberíamos tender a comentarios de una o dos líneas
*    a lo sumo: si alguna particularidad del código precisa de varias líneas, es preferible explicar
*    ese aspecto como prólogo a la rutina que usando un comentario de bloque.
**********************************************************************************************************)
    Los comentarios de bloque tienen varias ventajas:     Los comentarios de una línea se utilizan para aportar información adicional en ciertos puntos del código. Por ejemplo:
x[i] = a[j];        (* x[i] es ahora el mayor elemento *)
o bien:
temp := a[j];        { Intercambiamos los elementos máximo y mínimo }
a[j] := a[i];
a[i] := temp;
    Siempre que sea posible, intentaremos que los comentarios de una línea se coloquen en la misma línea que otras sentencias y a la derecha del final de la misma (como en los ejemplos), produciendo así un código más compacto.
    Muchos comentarios cortos juntos oscurecerán el código mismo. Si algún aspecto del código precisa muchos comentarios, es preferible incluirlos en un comentario prólogo al principio de la rutina que en varias lineas sueltas. Reserve los comentarios de una línea para situaciones como:     Un código con demasiados comentarios resulta tan malo como uno que carece de ellos. La cantidad de comentarios que se incluyen en un código no se puede establecer a priori (depende de la complejidad de las rutinas en cuestión) y del número de las mismas, pero en general, una buena regla es que un código debería contener un promedio de una línea de comentario por cada 10 líneas de código ejecutable.

    Reglas de tipo general

          a := a + 3;         { Se suma 3 al valor de a }

Legibilidad

Haga todo lo posible para incrementar la legibilidad de sus programas. En concreto:

Declaraciones

Utilización de constantes en el código

char c;
...
c = 97;                       /* Código ASCII del caracter 'a' */

Es preferible el siguiente:

#define ASCII_a    97        /* Código ASCII del carácter 'a' */
...
c = ASCII_a


A modo de resumen de esta regla podríamos decir que en el código no deberían aparecer constantes numéricas (salvo 0 y 1 por su uso frecuente) sino en su lugar, utilizaremos definiciones de constantes y el identificador de la misma en lugar de su valor.

Sentencia switch / case

Reglas de estilo

Indentado y disposición de los delimitadores

    La mayoría de los lenguajes de programación utilizan delimitadores (begin-end en lenguajes de tipo Algol, llaves en C, etc.) para delimitar las sentencias compuestas. La indentación debe utilizarse para reflejar tanto la estructura de control del código como las estructuras de datos utilizadas.
    Para indentar el texto del programa se pueden utilizar espacios o bien caracteres de tabulación, pero lo importante es seguir un criterio uniforme: si utiliza caracteres de tabulación (TAB), utilícelos siempre, no los mezcle con la otra alternativa.
    Otro problema es cuánto indentar: si se elige un indentado de más de 3 espacios el texto acabará "saliéndose" por la parte derecha de la pantalla. Recomendamos utilizar un indentado de 2 ó 3 espacios cada vez (si usa el editor vi, pruebe el comando set ts=2)
    En C, los delimitadores iniciales (llave abierta) se suelen añadir a otras líneas de manera que no ocupen ellas solas una línea. Por ejemplo, se suelen colocar en la misma línea que un if, for, while, etc., cerrarla justo antes de else y abrirla justo después, etc.:
for (i = 0; i < 7; i++) {
    alfa[i]++;
    if (alfa[i] == MAX)
        hallado = TRUE;
}
if (!hallado) {
    beta--;
    gamma++;
} else {
    beta++;
    gamma--;
}
    En lenguajes de tipo Pascal los delimitadores begin-end los colocaremos ambos en la misma columna, y encerrando el código que delimitan:
for i := 0 to 7 do
    begin
    alfa[i] := alfa[i] + 1;
    if alfa[i] = MAX then
        hallado := TRUE;
    end

El programa principal

    Normalmente la función principal (main en C) de un programa no realiza tareas importantes, es decir, en ella no se codifica la solución del problema. Sólo se encarga de invocar a los subprogramas que implementan la solución del problema.

Notas finales

    La documentación no debería ser lo último que se haga en cuanto a la escritura de un programa. La documentación es necesaria fundamentalmente en las primeras etapas del desarrollo del código más que cuando el mismo está ya acabado. Por otra parte, es cuando se codifica cuando se tiene claro el significado de lo que se está haciendo y el porqué se hace.
    Finalizamos el documento con una lista (breve) de recomendaciones (a modo de mnemónicos) que tratan de resumir algunas de las ideas presentadas anteriormente.

Bibliografía



Última actualización: el 17 de octubre de 2000 por F. de Sande
Copyright © 1999, F. de Sande
DEIOC - Centro Superior de Informática - Universidad de La Laguna. All rights reserved