10 Tips para Código Limpio

A pesar de la gran cantidad de lenguajes de programación, existen ciertas técnicas, que se pueden aplicar independientemente del lenguaje o plataforma en la que programemos.

Código limpio

Código limpio… suena bien, pero, no tengo tiempo para eso, tengo deadlines, presión por parte de mis jefes o clientes para que esté listo para mañana.

Y esto al final, no hace otra cosa que acabes con una gran bola sucia de código entremezclado.

En principio lo que queríamos es ir más rápido, para llegar a las fechas de entrega, pero es eso en realidad lo que pasa?

Mirad esta gráfica, que creo que representa muy bien el asunto. En la línea horizontal tenemos el tiempo invertido, mientras que en la línea vertical tenemos el coste que nos cuesta desarrollar ese código.

Cómo vemos desarrollar un código rápido y sucio al principio nos costará menos que un código limpio. Pero a medida que pasa el tiempo es realmente este código sucio un código rápido.

Yo creo que no…

Al hacer este tipo de código nos salen más bugs, así que tenemos que volver atrás, revisarlos, arreglarlos, y al final, esto nos va a costar más tiempo, si hubiésemos escrito un código limpio desde el principio.

Mejor prevenir que curar…

Hay estudios que se han hecho, en los cuales median en que empleaban el tiempo programadores reales, y descubrieron que el tiempo que pasamos leyendo código versus el tiempo que escribimos código, es de 10 a 1.

Te pasas 10 veces más leyendo código que escribiéndolo

La mayoría de nosotros se pasa más tiempo que si scroll para abajo, scroll para arriba, buscando cosas de un lado a otro.

A ver si estaba en este archivo… mmm… no, vamos abrir este otro… ah! no, este tampoco es… donde hice esto entonces?

El tiempo que te pasas tecleando es mucho menos que el tiempo que te pasas buscando y revisando el código.

Entonces, si empleas más tiempo en hacer tu código fácil de leer, será también más fácil de escribir.

Hay una frase de Douglas Crockford, uno de los creadores del formato JSON que dice algo así:

Esta frase define muy bien lo que nos suele pasar, nos pasamos la mayor parte del tiempo luchando contra ese código desordenado y caótico.

Entonces, ahora que creo que ya ha quedado claro por qué deberíamos hacer código limpio, vamos a ver 10 consejos para ello.

Consejo número 1: tú eres el responsable de la calidad de tú código

Ni tus clientes ni tus jefes lo son, tú lo eres. Si pensamos en otras profesiones, como abogados, doctores, la que sea. Cada una de ella tiene sus procedimientos estándares.

Imagínate que vas a que te operen de algo, y cuando va a comenzar la operación le dices al cirujano “sabes qué, no tenemos tiempo para que te pongas los guantes, ábreme ya vamos a terminar esto rápido”

Verdad que no hacemos eso, que tenemos un cierto respeto por cómo han de hacer las cosas, por sus procedimientos.

Si queremos que nos respeten a nosotros como profesionales, tenemos que actuar como profesionales. Y hacer las cosas de la manera correcta, y no aceptar otra forma que no sea la correcta.

Y depende de tí, crear estos procedimientos o estándares, no del cliente o de tu jefe.

Consejo número 2: utiliza nombres descriptivos

Por ejemplo en tus variables. Por ejemplo esta, d, que es el tiempo en días. La variable d por sí misma, no es que sea muy descriptiva.

Pero Kiko, si tiene un comentario para que sepamos lo que es

Sí, tiene un comentario, esta bien, pero una vez avanzas en el código, empiezas a ver otras variables con este tipo de nombres no muy claros, el esfuerzo mental que tienes que hacer para ir traduciendo estas variables a nombres con significado real te va llevar más tiempo, o incluso tendrás que volver a donde estaba ese comentario para ver qué es lo que era. Y esto con todas las variables que tengas.

Aquí vemos un ejemplo de la misma variable de antes, pero con un nombre más claro.

Grady Booch, que fue jefe científico en IBM decía:

Así que para ello debemos usar nombres claros para nuestras variables.

Consejo número 3: escribe código que exprese que es lo que va hacer

Nuestras funciones o métodos tienen que ser lo suficientemente claras para indicar que es lo que van hacer, si el anterior consejo era poner buenos nombres, este podría ser como poner buenos verbos, que son las funciones o métodos que realizan las acciones.

De esta manera, cuando uno lee el código, se entiende. Por ejemplo aquí vemos una función, estoy seguro que os podéis hacer una idea de lo que hace esta función, sin ni siquiera conocer el contexto donde se usa. Y puedes hacerlo incluso sin algo que falta, sabes que es?

Consejo número 4: el código debe hablar por sí mismo, menos comentarios igual a menos mantenimiento.

Hay una frase que me gusta mucho que dice

Muchas veces escribimos comentarios, porque estamos escribiendo un código, y no queda muy clara la intención de ese código, así que escribimos un comentario para explicarlo.

Pero en el momento en que estas escribiendo este comentario…

Estás escribiendo algo más que mantener a parte del código. Y lo que suele suceder es que cuando por ejemplo arreglamos un bug en el código, o hacemos una actualización, no nos damos cuenta del comentario, y ahora el que está mal es el comentario.

Vamos, sé sincero, cuántas veces te ha pasado esto?

Ahora el comentario se convierte en una mentira, y en un futuro para ti mismo o otra persona que coja el proyecto esa mentira te hará hacer cosas mal.

ojo! no quiero decir que nunca escribas comentarios!

Pero si hay que saber cuando escribirlos, por ejemplo cuando lidiamos con una librería externa o una API que no es nuestra, habrá comportamientos que tengas que explicar porque no lo podrás hacer sólo con tu código.

Así que cuando vayas a escribir un comentario, para, y piensa si quizás podrías haber escrito el código un poco mejor de forma que no necesites ese comentario que estás a punto de escribir.

Menos comentarios, menos mantenimiento, quédate con eso. Vamos a por el…

Consejo número 5: deja el código mejor de lo que te lo encontraste

En este caso, si tienes que actuar sobre un código ya existente, escribe esa nueva parte bien, de forma limpia, pero además de eso emplea un poco de tiempo mirando el resto del código, a ver si puedes mejorar algo, quizás sea algo tan simple como mejorar un nombre de una variable, o separar en varias funciones una función grande.

De esta manera, al contrario de lo que suele pasar, que solemos tener un código que se va volviendo cada vez más y más caótico, lo que tenemos es un código que va volviendo cada vez más y más limpio.

Consejo número 6: que tu código haga una cosa, y sólo una cosa

¿Qué queremos decir con esto?, pues bien cuando hacemos una función o un método, esta debe hacer sólo una cosa, y hacerla bien, pero sólo una cosa.

Una manera de identificar si lo estamos haciendo bien o mal es, si le pasamos a una función o método cuatro o cinco parámetros, o quizás más, es muy probable que esté haciendo más de una cosa.

Mientras más cosas haga una misma función, más difícil de debugar será. Por eso es importante que cada método o función se encargue de una sola cosa, y que la haga bien.

Consejo número 7: escribe pruebas o tests

Básicamente tenemos dos tipos de test para hacer nuestras pruebas de que todo funciona como ha de funcionar.

Primero tenemos las “Pruebas de integración” que testea como el usuario experimenta todo el conjunto del código.

Estas son las pruebas que te dicen “hey, has cambiado aquello de allí, y has hecho que esto otro se rompa”

Por otro lado tenemos las pruebas unitarias, que se encarga de testear cada parte del código por separado, por ejemplo a nivel de funciones o métodos.

Consejo número 8: trabaja sobre la imagen general del proyecto, y luego entra en los detalles

Es mejor empezar a trabajar sobre el esqueleto del proyecto, sobre esa estructura general de todo el proyecto, y luego entra en detalle en cada componente. Crea primero las interfaces, y luego al implementación de estas.

Consejo número 9: arquitectura independiente

Que quiero decir con esto, Bob Martin, que tiene varios libros tratando el tema del código limpio dice algo como esto:

Las arquitecturas de software son estructuras que soportan los casos de uso del sistema ...

Los frameworks son herramientas para ser utilizadas, no arquitecturas para ser conformadas.

Por ejemplo, vamos a pensar en Wordpress como un framework, entonces Wordpress es una herramienta para usarla, no una arquitectura para nuestro código. La idea es que la arquitectura se conforme de buenas prácticas se pueda aplicar en diferentes frameworks y lenguajes.

Por ejemplo, podemos crear un plugin para wordpress, que sea muy claro, que mirando los ficheros y los nombres de variables se entienda que es lo que hace, y de ese modo en con unos pocos cambios, podemos sacar este plugin de Wordpress y usarlo en otro framework. A la hora de hacer nuestro plugin, no lo pensemos como vamos hacer un plugin de wordpress, si no, más bien, vamos hacer una galería de imágenes, o lo que sea que haga nuestro plugin.

Vamos ahora con el último consejo...

Consejo número 10: práctica, práctica y práctica

Aprender nuevas técnicas cuando no tienes a nadie que te pague por ello es la manera en que realmente vas a mejorar tus habilidades.

Espero que te hayan servido estos consejos, y empieces a aplicarlos en tu trabajo. Me encantaría saber tu opinión sobre este tema, o si tienes algún consejo más que añadir. Dejamelo en los comentarios.

Suscríbete a nuestra newsletter para seguir aprendiendo cosas nuevas de desarrollo cada día, ¡es gratis!