"Clean Code" se popularizó como término gracias al libro homónimo de Robert C. Martin (conocido en la comunidad como "Uncle Bob"), publicado en 2008, que reunió en un solo lugar prácticas que hasta entonces circulaban de forma más dispersa entre distintos equipos. La idea central no es complicada: el código se lee muchas más veces de las que se escribe —durante la revisión, al depurar un bug meses después, al añadir una función nueva—, así que optimizar para que se lea fácil suele valer más la pena que optimizar para escribirlo rápido una sola vez.
Nombres que dicen la verdad
El ejemplo más simple y a la vez más ignorado: una variable llamada d o data no dice nada sobre lo que contiene, mientras que diasDesdeUltimoAcceso lo explica sin necesitar comentario. Lo mismo aplica a funciones: procesar() obliga a leer el cuerpo entero para saber qué hace; validarEmailYGuardarUsuario() ya avisa de que probablemente está haciendo dos cosas que deberían separarse.
Este principio se nota especialmente semanas después, cuando quien vuelve a leer el código —a menudo la misma persona que lo escribió— ya no recuerda el contexto que tenía en la cabeza al escribirlo la primera vez.
Funciones pequeñas que hacen una sola cosa
Una función que valida datos, hace una llamada a la base de datos y además envía un email es difícil de probar, difícil de reutilizar y difícil de entender de un vistazo. Dividirla en tres funciones más pequeñas, cada una con una responsabilidad clara, no añade líneas de código útiles —siguen haciendo lo mismo— pero sí hace que cada pieza se pueda leer, probar y modificar por separado sin tener que cargar con el resto en la cabeza.
No hay un número mágico de líneas que defina "pequeña", pero una señal práctica funciona bien: si al describir qué hace una función hace falta usar la palabra "y" más de una vez ("valida el email y guarda el usuario y envía la confirmación"), probablemente son varias funciones disfrazadas de una.
Comentarios: la señal de alarma, no la solución
Un comentario que explica qué hace una línea de código («// suma 1 a contador») casi siempre significa que el código no se explica solo, y la solución no es el comentario sino nombrar mejor o simplificar esa línea. Donde los comentarios sí aportan valor de verdad es explicando el porqué: por qué se eligió ese enfoque en concreto, o por qué hay una excepción aparentemente rara en la lógica —información que el código en sí no puede transmitir, por bien nombrado que esté.
DRY sin caer en la abstracción prematura
El principio de "no te repitas" (DRY) es útil, pero llevado al extremo desde la primera vez que se copia una línea genera abstracciones prematuras que a menudo terminan siendo más difíciles de seguir que la duplicación original. Una regla práctica que evita ambos extremos: la primera vez que se repite algo, se deja así; la segunda vez, se toma nota; a la tercera repetición, ya vale la pena extraer la abstracción común, porque para entonces suele estar más claro cuál es el patrón real y no solo una coincidencia superficial.
Cómo empezar sin reescribir todo el proyecto
Aplicar estos principios de golpe sobre una base de código grande y ya existente no suele ser realista ni buena idea. Funciona mejor aplicarlos de forma incremental cada vez que se toca una parte del código por otro motivo —renombrar una variable confusa, dividir una función mientras se añade una prueba— en vez de plantear una limpieza general que compita por tiempo con las funciones nuevas y casi nunca se termina.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!