Por que tienes que dejar de usar Else
Lunes de Bots & Bytes — Edición #03
Hola, por acá Danilo👋 Bienvenido a Lunes de Bots & Bytes 🤖
Cada lunes te enviaré un email con una idea breve de lo que haya aprendido o charlado durante la última semana acerca de RPA y Python.
También seguirás recibiendo artículos más largos de forma bisemanal, como este último:
Si te interesa aprender a construir robots más eficientes, escalables y fáciles de mantener, te invito a suscribirte.
Hace un par de años, conversando con un compañero acerca de clean code, me comentó que utilizar un else ensuciaba nuestro código y lo hacía difícil de leer.
En ese momento me choqueó la idea, hasta que me tocó ver y escrbir códigos largos, llenos de anidaciones y difícil de mantener.
Hoy en día, evito cada vez que puedo utilizar los bloques else en mis desarrollos y en este post te explicaré por que tu también tienes que dejar de utilizar Else.
La problemática de la anidación
Los bloques if-else pueden parecer inofensivos al principio, especialmente cuando nuestro código es corto y directo. Pero a medida que nuestro código crece y se vuelve más complejo, estas estructuras pueden llevar a múltiples niveles de anidación, haciendo que el código sea más difícil de leer y mantener.
La imagen de arriba fue un robot que me tocó revisar, el cual necesitaba validar diferentes condiciones a lo largo del flujo, y si no se cumplía alguna condición, se tenía que detener el robot.
Cláusulas de guarda
En lugar de sumergirse en una cascada de condiciones y anidar cada if, una solución que utilizo mucho es invertir la lógica. En lugar de validar si una condición es verdadera, evaluamos si la condición es falsa.
Veamos un ejemplo en Python 👇
Esto no solo hace mas simple el código, sino que lo hace más legible e incluso fácil de mantener. En lugar de tener la condición de stop o error al final de nuestro código, lo vamos creando al inicio de nuestro flujo, para facilitar la lectura.
Tener anidaciones hace dificil saber dentro de que lógica nos encontramos y realizar una modificación puede afectar nuestro trabajo.
Para esta técnica podemos utilizar "cláusulas de guarda" y manejar casos especiales o excepciones en un robot o método diferente, que se encargue de manejar la funcionalidad específica y así, en lugar de tener un robot enorme, tenemos diferentes robots que manejen casos y validaciones específicas.
Más sobre esto lo vimos en el post acerca de los principios SOLID:
Si modificamos el primero robot, nos quedaría de esta forma. Te dejo los dos casos.
Este es el robot original, donde cada parte del flujo está dentro de una validación. Ve como aumentan las identaciones 👀👇
Este es el mismo robot pero con la lógica invertida, donde quitamos todos los niveles de identación de las validaciones, dejando solo la de los ciclos for y ciclos while 😉👇
Y eso es todo por hoy! Si encontraste valor en este newsletter, considera alguna de estas cosas:
1) Suscribete a mi newsletter — Si aún no lo has hecho, considera convertirte en un suscriptor pago y podras agendar reuniones semanales conmigo.
2) Lee con tus colegas — El mejor agradecimiento es tu recomendación. Comparte este artículo con tu compañero que le pueda interesar y consigue membresías gratuitas a través del programa de referido
Ten una gran semana! 🚀
Danilo