Código hediondo

Hay ocasiones en que el código huele mal, es a lo que se le llama code smell. El termino que encontré en español es "código hediondo". No es código que tenga un error obvio, el código que huele mal no necesariamente está mal; pero debes darle una revisada y quizás reescribirlo  porque generalmente cuando hay mal olor significa que algo se está "echando a perder".

Cuando veas código que huele mal... sí, el olor del código se ve, incluso se puede detectar mientras se escucha al código... bueno, decía que sí ves código que huele mal, cámbialo en el momento, no lo dejes para después porque si trabajas mucho tiempo con código que huele mal, puedes acostumbrarte al olor y después no darte cuenta de que tu código apesta.

Algunos de los malos olores en el código son:

Código Duplicado

El código duplicado no es en sí un error. El problema es que no ayuda al mantenimiento del código. Hace que sea fácil cometer errores en el futuro, además de que te llevará más tiempo modificarlo. ¿Te ha tocado hacer un cambio en un programa y tener que ir a muchos partes del código a hacer el mismo cambio? No solo te tardaste más, también existe la posibilidad de que hayas olvidado cambiarlo en algún otro lugar y por lo tanto has introducido un  error.

Para prevenir el código duplicado, lo que puedes hacer es que cuando necesites que se ejecuten instrucciones en varios lugares, en lugar de copiar y pegar, mejor corta y pega. Corta la parte que se repite, pégala en un nuevo método, lo que cambia lo defines como parámetros y mandas llamar (o ejecutas) ese método donde lo necesites.

Método muy largo

El problema con los métodos largos es que es difícil leer que es todo lo que hace. Se complica poder entenderlo y por lo tanto lograr notar a simple vista como puedes afectar la funcionalidad del método al introducir un cambio.

Si el método hace muchas cosas es mejor llamar a otros métodos que hagan una parte chica cada uno. Por ejemplo: si tienes un método que genera un archivo con mucha información (como la factura electrónica). En lugar de tener todo el código en el mismo método, puedes dividirlo en métodos que escriben cada parte del objeto al archivo (un método para escribir los datos del emisor,  receptor, otro para productos, etc.).

Función con muchos parámetros

Este es un mal olor que se va dando con el tiempo, empiezas con uno o dos parámetros y todo se ve bien, luego agregas funcionalidad, necesitas más información  y le vas agregando más y más parámetros y a veces algunos de esos son opcionales. Al final puedes terminar con un método (o función dependiendo como le llame el lenguaje) que recibe muchos parámetros. No es un error; pero puede hacer más difícil entender el código.

Lo que puedes hacer es que cuando empieza a crecer el número de parámetros, en lugar de recibir muchos parámetros, recibir uno solo, un objeto o estructura con atributos (o propiedades) para cada posible valor. Algo como lo que hace jQuery (por ejemplo) con la función ajax, en lugar de recibir muchos parámetros, recibe un solo objeto con atributos para cada opción esperada.

Magic Strings

No solo aplica para las strings, también para los números. Las magic strings son valores literales que aparecen en el código. Por ejemplo cuando en ASP.NET tienes algo como [Authorize(Role = "Administartor")] si te fijas escribí mal el nombre del rol Administrator y no me voy a dar cuenta hasta que vea que todos los usuarios pueden acceder a ese recurso (no solo los que tengan el rol administrador). Con los números el problema no es que lo escribamos mal, sino que no sabemos qué es, si tenemos algo como if order.status = 2 then  es difícil saber qué significa ese 2 por lo tanto si quiero modificar el código debo tener cuidado.

El uso de constantes para los strings y el de enums en los enteros ayuda a prevenir este feo olor. Usa cosas como [Authorize(Role = Role.Administrator)] porque así si lo escribes mal puedes darte cuenta en tiempo de compilación. Tener cosas como if order.status = OrderStatus.InProgress then hace que sea fácil de saber que está pasando en el código.

Complejidad innecesaria 

Es como cuando usas una bazuca para matar una mosca. La complejidad innecesaria hace que el código sea más difícil de seguir, de entender y de modificar. El desarrollo se vuelve más lento y sin ningún beneficio. Este olor puede ser difícil de detectar, más por uno mismo. Es como la persona que se pone mucho perfume pero no se da cuenta porque siempre se pone y ya se acostumbro. No es que huela feo; pero no es agradable el perfume en exceso.

Algunos proyectos son más complejos que otros; pero no debes empezar de lo complejo a lo simple, sino al revés (para seguir con la metáfora, no te puedes ir quitando perfume). A veces sí ocupas dividir tu proyecto en varias capas; pero ve agregándolas cuando sientas que lo necesitas. No empieces agregando capas solo porque sí, después es más difícil quitarlas.

Estos son algunos de los olores que identifico, hay más; pero hasta aquí la dejamos por hoy. Mantén tú código oliendo bien, evita el código hediondo.