Cuando estas aprendiendo a programar te enfocas primero en la lógica, luego en el lenguaje y rara vez nos detenemos a pensar en la forma de hacerlo, es decir, como pasamos de la lógica al lenguaje. Es justamente el turno de revisar como debemos escribir este código, ver buenas practicas y como aplicarlas. El contenido de este post esta basado en el libro Código limpio(Clean code) de Robert C. Martin y también en mi experiencia. Lo estructurare tal cual esta dividido en el libro.

¿Por qué hacer código limpio?

Si estas leyendo este post, o estas interesado en el libro, eres programador o futuro programador, y crees en la necesidad de hacer un código elegante. No por simple capricho o ego, si no por que a medida que te internas mas en el mundo del desarrollo de software, puedes ver sus falencias. Mientras estaba en el primer semestre de mi especialización en Ingeniería de software, tocamos el origen de este problema, se remonta a la conferencia de Crisis del software que se celebro en 1968, esta se llevo a cabo con el objetivo de identificar causas y dar posibles soluciones a los problemas con los que se venia trabajando el software y aun en la actualidad continua. Se identificaron muchas causas y se dijo que la calidad de un producto se mide por su funcionamiento. En aquel entonces sirvió, y esto dio paso a definición de metodologías, arquitecturas y patrones de desarrollo de software, pero gracias a estas nuevas proposiciones se descubrieron nuevos problemas que estaban ocultos ¿Por qué te cuento esto?, por una sencilla razón, “Aquel que no conoce la historia, está condenado a repetirla“. Miremos ahora el problema que nos concierne, y que actualmente no es tratado como un problema real, si no como un añadido, ya que son pocos los que trabajan con estas pautas de código limpio. La pregunta mas lógica a continuación sería ¿por qué es un problema no trabajar con código limpio? La respuesta te la dará la experiencia, en mi caso llevo varios años trabajando y he sido parte de fracasos de software precisamente por este detallito, se hace el código, y por las prisas, trabajo represado y falta de compromiso como profesional se hace el desarrollo a la carrera, y esto no es el problema. El problema no es correr, el problema es salirse de la pista para coger un atajo. Por ejemplo, inicias con un proyecto, tienes todas las ganas de hacerlo bien, es tu bebe y debes mimarlo, hacerlo fuerte y también sentirte orgulloso de el, pero te piden algo nuevo, o cambian las fechas de entrega y debes correr, ejercen presión sobre ti para generar una entrega rápida y optas por hacerlo rápido y olvidarte de ciertos estándares o la forma de trabajo con la que venias usando. Luego con el tiempo esto se transforma en una bola de nieve, va creciendo con cada iteración que se da, y esto es un grave problema, por que llega un punto en el que el código se vuelve muy difícil de mantener, las personas que lo trabajan se aburren y lo dejan de lado, Se convierte en un ciclo donde un error genera otro error, hasta el punto en que se piensa en reestructurar toda la aplicación, para lastimosamente luego cometer los mismos errores.

Los lenguajes de programación han ido avanzando, encontramos desde lenguaje de maquina a lenguaje de alto nivel, que se acercan lo mas que pueden al lenguaje natural, pero si el programador es incapaz de expresarse correctamente su código estará lleno de errores, y los errores llaman mas errores. Otro caso, también podría ser que hagamos el código de afán y pospongamos el refinamiento, aquí entra la Ley de LeBlanc, que dice que después es igual a nunca, por eso, lo correcto es desde el inicio fijarnos un camino y seguir las buenas practicas y estándares. Debemos convertirnos en defensores del código elegante, del profesionalismo, eso hace parte de nuestra ética como ingenieros.

El código limpio debe cumplir ciertas características, ser de fácil lectura, eficiente, concreto, legible, mejora con cada iteración y no contiene duplicados. En el desarrollo de este post entenderás estos principios mas a fondo.

Nombres con sentido

En la programación todo el tiempo estamos utilizando nombres, para las variables, funciones, clases. Por lo que la primera regla para un código limpio es crear correctamente estos nombres.

Dicientes

Esto se refiere a la capacidad de expresar su propósito, dejar de lado aquellas variables de unas cuantas letras que no expresaban absolutamente nada.

 

Ejemplo de nombre de variable

//Incorecto
int a = 12;
//Correcto
int cantidadMeses = 12;

Diferentes

Los nombres de las variables, métodos, clases, etc. deben ser diferentes entre si y expresar correctamente su funcionamiento. Por ejemplo, supongamos que tenemos dos funciones, una se llama traerUsuario y la otra getUsuario. Esto nos puede llevar a una confusión y a perder tiempo revisando el código de cada una de estas funciones para verificar cual es la que necesitamos. Esto se puede evitar asignando nombres claros y diferentes.

No redundantes

Esto se refiere a no repetir las mismas palabras dentro de un nombre, ya que podemos confundir al lector. También lo podemos aplicar a no repetir los tipos de datos. Miremos el siguiente ejemplo:

Redundancia en los nombres

string nombreString = "";

La palabra string dentro del nombre esta de mas, y si es necesario especificar el tipo de dato, se aconseja que sean palabras diferentes a las reservadas por el lenguaje.

Pronunciación

Un dato que me pareció curioso y válido, es que pasamos la mayoría del tiempo de codificación, no escribiendo código, por el contrario, la mayor parte esta dedicada a la lectura del código. Por este motivo tanto énfasis en hacer un código limpio y legible, por eso cada bloque de código se debe poder pronunciar y acercarse lo mas que se pueda al lenguaje natural, claro esta sin excesos, tampoco podemos crear todo un párrafo como nombre de algún objeto, siempre hay que tener buen criterio y la experiencia y uso de estas técnicas son las que nos ayudaran a mejorar.

Codificaciones

Debemos evitar el uso de siglas o codificaciones propias, ya que lo que puede ser claro o evidente para mi, puede que no lo sea para los demás. Si se desea usar algún tipo de convención, sigla o codificación especial debe ser consensuada y compartida a cada integrante del equipo.

 

Para concluir este segmento y continuar revisando los principios del código limpio concluiremos diciendo que los nombres deben tener sentido dentro de su contexto, ser concretos, claros. Podríamos hacer una ejercicio, es tedioso y poco productivo, pero es muy educativo; podemos pasarla la lista de nombres a otra persona y si logra armar el contexto(clase) a partir de nuestros nombres de variables y funciones hemos realizado un excelente trabajo.

Algunas recomendaciones para nombrar clases es no usar verbos, por el contrario en las funciones se recomienda siempre usarlos. Y por ultimo, aunque parezca contradictorio, intenta hacer nombres cortos.