¿Qué tan seguido estás mirando el código de otra persona y pensás "Dios mio, esto es un spaguetti de código..."? Seguramente bastante seguido. ¿Y qué tan seguro estás que otra persona no haya pensando lo mismo de tu propio código? En otras palabras, ¿qué tan seguro estás de que tu código es limpio? El tema es que sólo podremos estar seguros si comprendemos completamente lo que significa hacer código limpio.
Resulta dificil crear una definición precisa de código limpio, y seguramente existan tantas definiciones como desarrolladores. Sin embargo, existen algunos principios que llevan a lograr un nivel básico de código limpio. Las 9 prácticas más relevantes para lograr codigo limpio a continuación.
1. El código malo hace demasiadas cosas - el código limpio es enfocado
Cada clase, cada método o cualquier otra entidad debería permanecer sin cambios. Debería cumplir con SRP (Single Responsability Principle, o Principio de Responsabilidad Única). Dicho de otra manera, una clase debe tener una y sólo una causa por la cual pueda ser modificada.
Podría no limitarse este concepto exclusivamente para clases. En un artículo, Ralf Westphal presenta una definición más amplia de SRP. De acuerdo a esta definición: "una unidad funcional en un nivel de abstracción dado sólo debería ser responsable por un único aspecto de los requerimientos del sistema. Un aspecto de requerimiento es un razgo o propiedad de los requerimientos, que pueda cambiar de forman independiente a otros aspectos".
2. El lenguaje con el que se escribió el código debería parecer que fue hecho para el problema
"No es el lenguaje lo que hace parecer simple a un problema, sino que es el desarrollador que hace que el lenguaje parezca simple" - Robert C. Martin
Esto significa, por ejemplo, que no debemos usar workarounds que hagan que el código y el lenguaje parezcan raros. Si decimos que algo sólo puede lograrse con un workaround, generamente significa que no invertimos el suficiente tiempo en intentar buscar una solución limpia y buena.
3. No debe ser redundante
Debería cumplir con la regla DRY (Don't Repeat Yourself, o No Te Repitas). Cuando se aplica correctamente el principio DRY, la modificación de un único elemento del sistema no requiere cambios en otros elementos que no tengan relación lógica.
4. Debe ser placentero leer el código
Cuando leamos el código debería parecer que estuvieramos leyendo a Harry Potter (bueno, quizás sea un poco exagerado...). Debemos sentir que es facil de leer por cualquier desarrollador sin pasar horas investigándolo.
Para lograr esto debemos cumplir con el principio KISS (Keep It Simple, Stupid!, o Mantenelo Simple, Estúpido!) y el principio YAGNI (You Ain't Gonna Need It, o No lo vas a necesitar). El principio KISS indica que la mayoría de los sistemas funcionan mejor si se los mantiene simples en lugar de complejos.
Por lo tanto, la simplicidad tiene que ser un elemento clave del diseño, y se debe evitar la complejidad innecesaria. YAGNI es una práctica que nos alienta a enfocarnos exclusivamente en las cosas más simples que hagan funcionar al software.
5. Puede ser extendido facilmente por cualquier otro desarrollador
No escribimos código para nosotros mismos, o peor - para el compilador. Escribimos código para otro desarrollador. No seamos egoístas: pensemos en los demás. No torturemos a otros desarrolladores creando código que es dificil de extender y mantener. Además, en algunos meses es posible que nosotros mismos seamos el "otro desarrallador".
6. Debe tener dependencias mínimas
Mientras más dependencias tenga, más dificil va a ser de mantener y cambiar en el futuro. Existen herramientas que nos ayudan a cumplir este objetivo, marcando las dependencias "extrañas" de nuestro código.
7. Más chico, mejor
El código debería ser mínimo. Tanto las clases como los métodos deberían ser cortos, preferentemente con pocas líneas de código. Debe estar bien dividido. Mientras mejor dividamos el código, más facil se vuelve leerlo. Este principio puede influenciar positivamente al punto 4 - va a facilitar la comprensión del código cuando lo lean otros desarrolladores.
8. Debe tener pruebas unitarias y de aceptación
¿Cómo podemos saber que nuestro código cumple con los requerimientos si no escribimos pruebas? ¿Cómo podemos mantener y extender el código sin miedo a romper algo? El código sin pruebas no es código limpio. Si querés aprender más sobre los pilares de las pruebas unitarias, podés leer el artículo Three pillars of unit tests.
9. Debe ser expresivo
La expresividad del código significa que tiene nombres significativos. Estos nombres deben expresar la intención. No tienen que resultar engañosos. Tienen que ser distintivos. La expresividad hace que el código se documente a si mismo, resultando en que sea menos importante la documentación. Si quieren aprender más sobre el tema del código auto-documentado pueden leer este artículo.
