sábado, junio 02, 2007

Escribiendo Código Legible

Actualmente nos encontramos trabajando en una aplicación, de esas que uno llamaría "grandes" y "de alto impacto". Como es usual, debemos entregarla en tiempo record, y dado la naturaleza de los requerimientos solicitados, tiempos de entrega y demás variables involucradas en la gestión de este proyecto, el equipo de desarrollo se encuentra, en su totalidad, trabajando tanto a nivel de codificación, programación, análisis, diseño, control de calidad... en esta aplicación.

Es entonces en este tipo de proyectos, en donde no es uno, ni dos, sino varios programadores los que se encuentran codificando diversos módulos en la misma aplicación y que en un momento estarán interactuando, que uno se da cuenta de la necesidad de escribir Código Legible, ya que por la naturaleza del desarrollo, no es el autor del código el único que va a leer sus creaciones, sino que en alguna instancia, otro programador se va a ver en la necesidad de leer su lírica (por decirlo de alguna forma)... y de verdad, hay veces, la mayoría, que en lo personal cuando veo el código de otro compañero, me pregunto "qué m.... es esto???"... no les pasa a veces?

Comentar el código no es algo que debe dejarse para luego, para después de que la aplicación se entregue, y mucho menos... no hacerlo, es algo que se debe realizar sobre el camino. Claro está, comentar código es una de las tantas técnicas disponibles para escribir código legible.

"Como desarrollador, el tiempo es tu recurso más valioso ... un minuto dedicado a escribir comentarios puede ahorrarte una hora de angustia" - Jeff Vogel

En esta ocasión presento un resumen de un artículo que me encontré hace un par de días, y no precisamente es uno de esos artículos escritos hace meses o años, es uno realmente nuevo: "Six ways to write more comprehensible code" (Seis formas de escribir código más legible) escrito por Jeff Vogel, Presidente de Spiderweb Software. En éste, el autor dicta seis consejos para escribir código legible basado en sus más de 10 años de experiencia como desarrollador de juegos de computadoras.

Parece mentira pero cuando lean los consejos que presenta este artículo, dirán: "esos eran los consejos?... pero si eso ya lo sabía!"... y es verdad... todos sabemos que esto se debe hacer... el detalle es que no lo hacemos. Semejantes reglas o mejores prácticas son estrictamente seguidas por grandes empresas como Infosys Technologies Ltd., los desarrolladores y programadores que trabajan en compañías como estas deben seguir estrictamente ciertos lineamientos al momento de escribir códigos, ya que son fuertemente evaluados cuando sus desarrollos llegan a Control de Calidad.

A continuación un extracto de los consejos presentados en el artículo en cuestión:

  1. Escibe comentarios inteligentes:
    El Tiempo es tu recurso más valioso. El tiempo perdido jamás podrá recuperarse. Los comentarios deben ser claros como el agua, de otra forma se estará desperdiciando tiempo futuro. No deben ser tan largos que te duerman, ni tan corto que no logren explicar o describir una idea concisa. Tampoco es que se va a comentar lo obvio.

  2. Utiliza constantes. Pero no MUCHO:
    Tanto el uso de constantes como el lugar donde éstas se definen es de gran ayuda al momento de hablar de mantenimiento. Muchos programadores saben, hasta cierto punto, hacer este tipo de cosas. Pero ello requiere disciplina para hacerlo adecuadamente. Y no solo ello, sino también el nombrar adecuadamente estas constantes influye directamente en el objetivo, lo cual nos conduce hacia el siguiente consejo.

  3. No uses confusos nombres de variables:
    El objetivo general es simple: escribe código de tal forma que, si alguien lo lee y no tiene idea de qué es lo que hace, pueda entenderlo y saber lo que hace tan rápido como sea posible.
    La estrategia para lograr esto es dar buenos nombres descriptivos a tus variables, procedimientos y similares.

  4. Haz revisión de errores:
    Al momento de crear tu procedimiento/función, debes siempre pensar: "Supongamos que a alguien se le ocurre la brillante idea de meter todos estos incoherentes e insensatos valores. Cómo se defenderá mi código y evitará que se congele el sistema o incluso la máquina?" A partir de esta suposición que entonces tengas que escribir tu código y validarlo contra esta carga de extraños valores.

  5. "La optimización prematura es la raíz de todo el mal" - Donald Knuth:
    La raíz de la frase expuesta, pueden encontrarla rápidamente y en su versión original en inglés en Wikipedia.
    A menos que desees hacer sufrir a la gente, tu principal meta, al escribir código, deber ser claridad. El escribir código simple es bastante rápido, bastante rápido el entenderlo al regresar a él, y bastante rápido de corregir.
    La optimización es el enemigo de la claridad. A pesar de ello, a veces, se debe optimizar.
    Escribe algo limpio, claro y que funcione. Tienes todo el tiempo del mundo para optimizar posteriormente. El detalle está en no hacerlo sino hasta estar seguro de que lo que intentas hacer, se esté haciendo de la forma correcta.

  6. No juegues de Sabelotodo:
    La moraleja aquí es que si el código que estás escribiendo requiere conocimiento detallado de reglas intrincadas de precedencia o te conduce a echar un ojo a algún capítulo de uno de esos libros para saber lo que estás haciendo, estás siendo un sabelotodo.
    "Si tu código requiere conocer la diferencia entre i++ y ++i ... tu código es demasiado complicado", Jeff Vogel.
Una vez más, estos son consejos, leves tips para mejorar la legibilidad de tus códigos y hacerle la vida un poco menos complicada a tus compañeros de trabajo, lo importante aquí es tomarlos en cuenta.
Fuentes consultadas:

+ Six ways to write more comprenhensible code
+ Notación Húngara

2 comentarios:

Anónimo dijo...

Hola

Tal vez te interese esta guía de programación en castellano con multitud de consejos de estilo - desde nombres de variables hasta cómo escribir pruebas.

http://www.ahristov.com/tutoriales/Blog/Estilo_de_Programacion.html

ecs dijo...

gracias por la recomendación... lo más seguro es que una vez halla estudiado el documento haga una publicación al respecto