En este artículo haré un resumen del libro titulado originalmente: "Clean code: A handbook of agile software craftsmanship" publicado en 2009 y cuyo autor es Robert Cecil Martin. Su versión en español se titula "Código limpio: Manual de estilo para el desarrollo ágil de software".

Este resumen es en mi opinión una lectura ligera y sin embargo rigurosa sobre un tema muy relevante para todo desarrollador de software, programador, científico de la computación, ingeniero, project manager, analista de sistemas, y entusiasta de las ciencias de la computación con interés en generar código de calidad, ya que de alguna manera u otra todos los mencionados estarán relacionados con el código a lo largo de su vida profesional.

Tal como el libro de 644 páginas lo menciona al iniciar, cada año se invierten muchas horas y se pierden numerosos recursos debido a código deficiente, es decir mal escrito, y esto repercute en la velocidad del desarrollo y disminuye la productividad, a su vez todo esto genera graves fallos o hasta puede terminar con la organización completa llevándola al fracaso.

Conociendo esto, es entonces muy importante, no sólo aprender un lenguaje de programación y un framework, sino aprender también a utilizarlo de la mejor manera. Te lo pongo en estos términos:

Escribir código porque aprendimos la sintaxis pero sin aplicar los principios del código limpio es como memorizar las palabras de un diccionario pero sin aprender a expresar nuestras ideas claramente.

Cabe destacar que el prólogo, escrito por James Coplien hace mención de uno de los pilares del enfoque de calidad TPM llamado las 5s, la famosa metodología japonesa creada en los años 60 por Toyota y que está basada en los 5 principios: Clasificación, Organización, Limpieza, Estandarizar y Mejora contínua. Para él, la práctica del software require disciplina y esta metodología lo representa bien.

Definición de "código limpio"

El libro plantea varias definiciones hechas por destacados desarrolladores y científicos de la computación, a continuación te diré las definiciones que cada uno de ellos hizo:

• Bjarne Stroustrup, el inventor de C++

De acuerdo con Bjarne, el código limpio es aquel que es elegante y eficaz, con una lógica directa y sin misterios y un rendimiento óptimo.

• Grady Booch, autor de Object Oriented analysis and design with applications

El código limpio es simple y directo, se debe leer como si de un texto bien escrito se tratara. Aquí Grady hace especial énfasis en la legibilidad.

• Dave Thomas, fundador de OTI

Dave por su parte señala que un código limpio es aquel que cualquier programador puede leer o mejorar, no sólo el autor del código.

• Michael Feathers, autor de Working effectively with legacy code

Para Michael el código limpio es aquel código que siempre parece que lo ha escrito alguien a quien le importa.

• Ron Jeffries, uno de los tres inventores de la metodología de desarrollo de software extreme programming (junto a Ward Cunningham y Kent Beck) y autor de Extreme programming adventures in C#

Ron es más específico y objetivo, según él el código limpio es aquel que cumple estas condiciones: ejecuta todas las pruebas, no contiene duplicados, expresa todos los conceptos del diseño del sistema, minimiza el número de entidades como clases, métodos, funciones y similares.

• Ward Cunningham, co-autor de Using pattern languages for object-oriented programs (libro que escribió junto a Kent Beck) pionero de los patrones de diseño y uno de los tres inventores de la metodología extreme programming. En esta entrada te cuento toda la historia de los patrones de diseño.

Según Ward, un código es limpio cuando cada rutina que leemos resulta ser lo que esperábamos

• El propio autor, Robert C. Martin

Un código es limpio cuando es fácil de leer, fácil de entender y fácil de modificar.

Bob destaca que el código debe escribirse pensando en el lector y no sólo en la máquina.

En resumen, un código es limpio cuando puede ser entendido de una forma fácil por cualquier persona del equipo, cuando puede ser leído y mejorado por un desarrollador distinto al autor del código. De esta forma, junto con la comprensibilidad del código llegan también otras características deseables como legibilidad, capacidad de cambio, extensibilidad y mantenibilidad.

Secciones principales

El libro se divide en tres partes.

• La primera parte hace una descripción de los principios, patrones y buenas prácticas para crear un código limpio.

• En la segunda parte se incluyen casos de estudio ordenados por complejidad.

• Finalmente en la tercera parte del libro se hace una lista de heurísticas y síntomas de código erróneo, o lo que el autor llama smells. Estos "smells" se han creado a partir de los casos de estudio de la segunda parte.

El universo se rige por principios físicos universales, es evidente que hubo un diseño inteligente en él y por eso todo se mantiene en orden y armonía. Tu código debería tambien regirse por principios para que sea lo más armónico posible, para hacer un buen frente ante la complejidad cada vez más creciente.

Principios generales

El libro plantea cuatro y son los siguientes:

• Sigue un estándar de código, utiliza las convenciones existentes.
• Mantenlo simple, lo siempre siempre es mejor, reduce lo más que puedas la complejidad. Este principio lo plantea como KISS (Keep it simple stupid o como prefiero usarlo yo, Keep it simple Simon)
• La regla del boy scout. Los boy scouts siguen la siguiente regla: "Deja el campamento mejor de como lo encontraste" esta es una variante de la frase hecha por el creador del escultismo (movimiento de scouts) Robert Baden-Powell "El scout deja el mundo mejor de como lo encontró". En el ámbito del código esto quiere decir que mientras estés trabajando en una pieza de código siempre que sea posible déjala mejor de como la encontraste, es decir mejora tu entorno de trabajo.
• Busca siempre la raíz del problema, no te contentes con parchar algo, sigue la pista y corrige el problema de raíz.

Principios de diseño

Aquí podemos señalar seis, las cuales son:

• Mantén la información de configuración en niveles altos.
• Da preferencia a utilizar polimorfismo en reemplazo de las estructuras condicionales IF/ELSE y SWITCH.
• Separe el código multi-hilo.
• Evita la configuración excesiva.
• Utiliza inyección de dependencias.
• Aplica la "Demeter law", es decir que una clase sólo debería conocer a sus dependencias directas.

Esto es en líneas generales los principios más generales planteados en el libro, después podemos también considerar otras dos cosas importantes:

• Reglas específicas: Como las convenciones sobre nomenclatura o nombramiento de variables, cómo realizar comentarios de código, cómo hacer funciones bien hechas, tests o los llamados code smells.
• Ejemplos prácticos de estos principios y reglas hechos en código.

Esos dos puntos muy interesantes para analizar serán motivo de otros dos artículos, así que mantente a la expectativa.

Si este artículo te ha gustado, considera compartirlo estimado entusiasta de la programación 🧑‍💻👩‍💻🫡

Créditos fotográficos: La imagen de la portada es la galaxia M104, foto de Guillermo Ferla en Unsplash