Las 9 cualidades del código limpio

Las 9 cualidades del código limpio

Publicado: Lunes, 21 Enero 2013 17:53

¿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

...