Estilos de codificación (Carlos Fontela)

Como dije en otro artículo, no hay mejor documentación interna que el propio código. No hay comentario que arregle un código ilegible, y la legibilidad es un atributo de calidad de primer orden.
Esto es así porque, en la mayoría de los casos, un programa se lee muchas más veces de las que se lo edita. Por eso, debemos entender que programar es mucho más una tarea de comunicación con otras personas que una comunicación con una computadora.

Por todo eso es importante respetar estándares de codificación – oficiales o no, pero que se siga un estándar – y lograr que la estructura del código fuente refleje la estructura lógica del programa.

En primer lugar, si lo que queremos es comunicarnos con otras personas, deberíamos seguir las recomendaciones que desde hace siglos existen sobre cómo escribir bien.
Por ejemplo, cuando escribimos un libro, utilizamos un sinnúmero de ayudas para el lector: espacios en blanco, signos de puntuación, sangrías, renglones en blanco, títulos de distintos niveles, paréntesis, etc. Con todo esto tratamos de que el lector capte el sentido de lo que queremos decir.
Cuando escribimos programas también podemos utilizar este tipo de ayudas al lector, y de hecho es conveniente que lo hagamos. Tenemos ayudas posibles como sangrías, paréntesis innecesarios pero convenientes, nombres claros, líneas en blanco, separación de partes con caracteres especiales, encabezados de módulos de distintos niveles, etc.

Otra cosa que podemos hacer es contextualizar lo que escribimos, separando adecuadamente niveles de lectura.
En estas condiciones, la parte de más alto nivel de un programa no tiene que tener detalles de implementación de bajo nivel. Por ejemplo, tipos como ArrayList no deberían llegar hasta las clases de más alto nivel. Éstas deben ser, en la medida de lo posible, clases conceptuales, tomadas del dominio del problema.
Lo ideal es mantener distintos niveles de abstracción y programar en cada uno según el dominio de ese nivel. Desde ya que la POO ayuda mucho con su idea del encapsulamiento.

En línea con lo anterior, utilicemos la organización de archivos para emprolijar nuestro código fuente. La práctica habitual es que cada clase va en un archivo que lleva su nombre. En C++ se suele separar un archivo de encabezado. También hay recomendaciones sobre las extensiones utilizadas. Si respetamos estas reglas haremos más sencilla la búsqueda de fuentes en un sistema mediano.

En otro orden de cosas, no trabajemos como si nos multaran por cada carácter de más en nuestros fuentes, que luego sólo pueden leer extraterrestres. Por ejemplo, los lenguajes derivados de C se prestan mucho para escribir programas compactos. La gran mayoría de los programadores C está acostumbrado a escribir y a leer estos programas.
Notemos que el fragmento que sigue:

for (ini = 0, fin = n; ini<fin && capicua ;ini++, fin–)
capicua = (s[ini] == s[fin]);

Se puede escribir en código más compacto (pero menos claro) así:

for (ini = 0, fin = n; ini<fin && (capicua = (s[ini] == s[fin])) ;ini++ ,fin–)
;

Donde el ciclo for ha quedado vacío.
Recordemos, para no caer en código ilegible, que la legibilidad de un programa es inversamente proporcional a lo compacto de su escritura.

Una cuestión que a veces no queda clara de la lectura del nombre de algunas variables es la unidad en la que están expresados los valores. Por ejemplo, si tengo una variable precio, ¿contendrá el monto en pesos o en reales? Y esta distancia, ¿estará en centímetros o en milímetros?
Una buena práctica es incluir la unidad en el nombre, como en precioEnPesos o distanciaEnMm.

Y, en líneas generales, conviene utilizar algoritmos legibles, métodos cortos, buenos nombres, constantes y no valores, no usar nombres con más de un fin y evitar anidaciones excesivas.

Una buena modularización ayuda también. En el caso de aplicaciones medianas o grandes es ilusorio pretender mirar todo el código, con lo cual la abstracción en métodos, clases y paquetes de nombres claros, o basados en patrones conocidos, es de gran ayuda.

Advertisement

Etiquetas: Calidad, Diseño, Programación