escoba¿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.

Traducido de Top 9 qualities of clean code, por Pawel Bejger.
  • Sin duda que así debería de ser, sin embargo me pregunto, ¿Por qué no siempre lo cumplimos? Buena entrada, genio.

  • [quote name="Guest"]Sin duda que así debería de ser, sin embargo me pregunto, ¿Por qué no siempre lo cumplimos?.[/quote] Michael Feathers dijo: "el código limpio es aquel escrito por alguien que le importa". Creo que tiene un muy buen punto ahí. Cuando el código reallmente nos importa, buscamos aprender e implementar técnicas para dejarlo lo mejor posible. Yo creo en el "código bello", ese código que lo mirás y se ve "lindo". El código como arte, si se puede decir.

  • Invitado

    Buena la entrada. En lo personal no creo en el código como arte. El arte debería buscar la estética y la belleza, mientras que la ingeniería (en este caso la informática) debería buscar la funcionalidad, puediedo alcanzar o no la belleza. Y, en mi caso, no me interesa alcanzarla. O sea, no pagaría la entrada de un museo para ver el código de un sistema de ABMs XD XD Pero un código ordenado y limpio, que pueda entender otro colega (y también uno mismo luego de 2 días de no verlo :) ) siempre es algo deseable. Muy bueno el post.<br />abz

  • Invitado

    Gran post, varios de los puntos mencionados están en Clean Code, y me gusta como lo explicas

  • moldes nordic ware baratos

    Muy de acuerdo con el post. Que un código funcione no es lo único importante. Un código limpio es elemental para evitar futuros problemas y solucionarlos fácilmente.

Deja tus comentarios

Post comment as a guest

0

Seguinos en Facebook.

Publicá tus artículos.

Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
Quiero publicar

Los Comentarios.

Hanna Taller
Measure indicators of your commercial performance with mobile applications android and ios using ric...
Alinamike
Great step you have define it is really helpful for all developer making a website
Dai
Es broma?
busquen el significado de cinismo.
esta el antiguo significado y el moderno,
el moderno...
Yan
Hola:
Unas duda, Drools ¿tiene una interfaz gráfica para poder generar y editar reglas? o todo se t...
Maxi
Gracias por la info, esta bien explicado y funciono como solución a mi problema que tenia con el mét...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw