La importancia de un código limpio

Para los que leemos y escribimos código todos los días, es fundamental que éste cumpla ciertas características. No sólo por nuestra salud mental, sino también porque es un aspecto clave a la hora de mantener aquello que se llama la “calidad el código”.

Este artículo está motivado por algunas perlas que se escuchan a diario en muchos equipos de desarrollo de software. Aquí van tres de las mejores:

Perla 1: “Bueno, ¿qué más da la indentación del código? funciona igual”

A primera vista, la existencia de beautifiers para cualquier editor de código que se precie, estándares y guías de estilo, o incluso de lenguajes de programación en los que hay que indentar el código obligatoriamente (Python, Haskell, Occam…) nos hace pensar que algo de importancia tiene.

Cuando nos dicen que se ha detectado un bug en una aplicación, abrimos el fichero en cuestión y tenemos que leer el código como si viéramos un partido de tenis, sabemos que la tecla Tab es la más importante del teclado. He aquí un ejemplo:

Los dos casos compilan, y hacen exactamente lo mismo. Pero si tenemos que leerlo, la cosa cambia. ¿Quién se anima a modificar el primer caso sin contar las llaves de apertura y cierre? En el segundo caso, sería inmediato.

Perla 2: “Es una función muy sencilla, no pierdo tiempo en pensar nombres para las variables”

Si vivimos en un sector cada vez más agile, resulta lógico aplicar esa agilidad desde la base. La metodología SCRUM se basa en buena parte (y dicho a grandes rasgos) en que la documentación reside en el propio código, el cual debe contener nombres de variables autoexplicativos, estructuras claras y rápidas de comprender de un simple vistazo. Esto aumenta exponencialmente la velocidad a la hora de modificar el código y solucionar incidencias.

Perla 3: “No voy a comentar el código, si yo lo entiendo perfectamente”

Grave error. Supongamos que, en un momento de inspiración, escribo un método de quince líneas llamado acertarLaPrimitiva(). Declaro 5 variables a, b, i, n y z en la primera línea, mientras que en el resto encadeno unos cuantos forEach(), map(), fromPairs() y un par de nth(). Partiendo de la premisa de que todo el código necesita mantenimiento y modificaciones posteriores, y que no recuerdo lo que comí ayer, más me vale incluir una cabecera comentando qué hace esa función, qué argumentos recibe y qué valores devuelve. De lo contrario, adiós a mi jubilación en el Caribe.

¿Qué pensaría cualquier lector si este post estuviera redactado sin utilizar signos de puntuación? Siempre que se escribe es para que alguien lo lea; en nuestro caso el código lo leen personas y máquinas, y tenemos que pensar en los dos casos.

Tenemos un código limpio, documentado, fácil de leer y con una estética digna de mostrar al mundo, pero.. ¿cumple el objetivo? y, si lo hace, ¿lo podrá cumplir también dentro de un año con unas simples modificaciones?. Recordemos que el código de calidad cumple cuatro reglas:

Correcto: nuestro código debe compilar (¡qué menos!) y funcionar correctamente, haciendo exactamente lo que se espera que haga, ni más ni menos. Tan malo es que nuestro método acertarLaPrimitiva() encienda el horno, como que sólo acierte la mitad de los números.

Robusto: lo contrario a “cogido con alfileres”, a provocar un incendio en la consola si no hay espacio en disco o a forzar un logout si el servicio web al que llamamos nos devuelve un resultado no esperado.

Mantenible: escribimos programas que otras personas leerán en un futuro, cuando tengan que modificar su funcionalidad o solucionar bugs. En esto consiste el mantenimiento del código, algo que en la mayoría de proyectos supone más tiempo, esfuerzo y coste que la construcción inicial. ¿La razón? código enrevesado, poco comprensible, acoplado y con fuertes dependencias.

Reusable: si escribimos un código que cumple las tres premisas anteriores, ¿por qué volver a escribirlo de nuevo cuando necesitemos hacer lo mismo? Cuando construimos clases, métodos o arquitecturas con bajo acoplamiento, la mayoría de sus piezas son intercambiables. Si acertarLaPimitiva() contiene un algoritmo mágico para acertar números de lotería, ¿podríamos renombrarlo a acertarNumeros() y prepararlo para enfrentarse a todo tipo de sorteos?. Para ello es fundamental realizar abstracciones de elementos similares.

El código se escribe una vez, pero se lee y se modifica muchas más. Existe muchísima literatura acerca de la limpieza, principios básicos del buen desarrollador y herramientas para aplicarlos, pero quizá uno de los mejores sitios para empezar sea el libro “Clean Code. A Handbook of Agile Software Craftmanship”, de Robert Martin. Si, tras leerlo, vemos una función de 60 líneas y nos amarga el día, es una buena señal ;)