sábado, febrero 20, 2016

Buenas Maneras (I): Llaves e identaciones

Inauguro una pequeña guía de estilo de como me gusta encontrar un código cuando trabajo en él (llamadme maniático si queréis).

A la hora de diseñar e implementar un nuevo firmware (o programa) no tengo mucho problema, ya que lo hago a mi gusto, sin embargo a la hora de mantener un programa o firmware realizado por otra persona es donde me suelo encontrar los problemas... Depende de lo hijop#t@ "limpio" que sea el programador anterior, que el código este comentado, indentado correctamente y bien diseñado.

Existen muchas guías de estilo (de hecho todos los proyectos grandes tienen la suya propia), pero yo me he hecho la mía a lo largo de los años y he notado que los errores se reducen y me es más sencillo leer y entender código antiguo.

Para no liarnos escojamos un lenguaje de programación de base: C++. Escojo este porque permitirá hacer comentarios tanto para lenguajes de bajo nivel (C), como para alto nivel (Java o C#).

Hoy vamos ha hacer algunos comentarios del estilo básico a la hora de escribir un programa (lo que llamaríamos la caligrafía).

Antes de empezar

Antes de empezar hay que tener en cuenta ciertas cosas:
  1. La guía de estilo debe ser clara en todas las situaciones. Yo recomiendo partir siempre de alguna guía ya establecida en un proyecto grande, de esta forma habrá muchos temas ya contemplados y que ni siquiera se nos habrían ocurrido en el primer momento (a título personal yo uso la guía de ANSI de base).
  2. La guía de estilo debe ser la misma para todos los participantes de un proyecto. No es nada agradable ver distintas partes del proyecto formateadas de forma diferente, además es confuso y puede llevar a errores.
  3. La guía de estilo debe ser estable en el tiempo de vida de un proyecto. Las guías de estilo no son inmutables, todo el mundo incorpora prácticas nuevas y mejores en su programación, sin embargo en un mismo proyecto es importante mantener la misma guía de estilo a lo largo de todo el tiempo de desarrollo para no crear confusión a la hora de leer el código. Aquí hay dos opciones, o se mantiene el estilo anterior o se cambia en todo el código. Hacer una u otra cosa dependerá de muchas cosas pero si se va a cambiar todo el código hay que tener en cuenta que haremos una pequeña ruptura con el código anterior (sobretodo si utilizamos un control de versiones), y hay que hacerlo de forma muy controlada.
  4. Se debe automatizar el proceso. Independientemente que interioricemos el proceso de escritura es importante usar un IDE que puedas automatizar el proceso de corrección de estilo (la mayoría de los IDEs modernos ya tienen esta opción incluida), de esta forma será mucho más sencillo. Sin embargo, en ningún caso implica que debamos dejarlo todo al IDE, en multitud de ocasiones no tendremos la oportunidad de realizar la automatización, por lo que será bueno que nos acostumbremos a escribir el código según la guía que hallamos elegido.

Llaves e identaciones

Primera regla de las identaciones usad siempre tabulaciones y no espacios esto incluye a no convertir las tabulaciones en espacios. A parte de ser una manía mía, implica desplazarse por el código más rápido y evita desajustes en el código cuando se tocan accidentalmente las teclas Supr o Retroceso. Sólo recomiendo usar los espacios para casos extremos en los que no haya más remedio (cuando no se puedan usar tabulaciones como el caso de esta bitácora). Otra cosa, las identaciones que ocupen el tamaño de 4 espacios (esto generalmente se puede utilizar Veamos ejemplos incorrectos, a mi modo de ver, de usar las identaciones:

¡¡¡ HORROR !!!, esta forma de programar hace que el código sea cada vez más ilegible (sobretodo cuando llevas 10000 líneas de forma similar). La solución correcta sería:

Sí, ya se que queda más largo el código, pero queda más limpio y te deja sitio para poner los comentarios que hagan falta. Por cierto poner !i o poner i==0 no es indiferente, la primera se deberá utilizar cuando sea una variable de verdadero o falso (booleano) y la segunda cuando sea una variable numérica. Otro:

 Esto queda feo con ganas, a parte que (personalmente) le tengo una manía horrible a poner la llaves no de forma identada (que empiece el bloque y lo acaben en la misma columna), y sobretodo cuando en vez de a=0 hay 100 líneas de código te puedes perder. Quedaría así:

o en este caso que tenemos una sóla línea:

fácil limpio y corto. Sin embargo es recomendable utilizar la primera opción para que las llaves limiten el bloque (menos propenso a errores). Otro ejemplo con la instrucción switch, partirmos de:

Cuando tenemos que hay mucho código dentro de los case queda muy sucio y poco comprensible. Una buena forma de no perdernos sería:

Así tenemos alineado el código y dentro de unas llaves, por lo que será más legible y más fácil de seguir. Siguiendo con el switch es bueno que la variable a sea de tipo enum (no siempre se puede), de esta forma podremos hacer un código más descriptivo, y por lo tanto más sencillo de leer.


Más adelante seguiremos avanzando con este y otros temas que nos permitirán aumentar la productividad a la hora de escribir y corregir código.

S2

Ranganok Schahzaman