«Cómo puedo hacer mi código más fácil de entender?»

Esta es una pregunta que debemos hacernos a nosotros mismos si queremos mejorar la forma en la que escribimos código y en pro de aplicar buenas prácticas, 2 de las muchas razones del porqué que tenemos por preocuparnos en escribir buen código son:

  1. No importa el tamaño de tu equipo, sea grande o pequeño, estás creando código para el futuro, a qué me refiero? Es muy probable que no seas el único que agregue código al proyecto. Y es mejor que sea un código entendible para que el proceso de onboarding de los nuevos integrantes sea más corto.
  2. El tiempo que inviertas “extra” en hacer tu código más entendible, es un tiempo que te ahorrarás después tratando de entender lo que hace esa porción de código y explicarles a otros.

Tu código no va a ser perfecto en un entorno productivo, con plazos ajustados, trabajar con el código existente a veces no se puede hacer de la manera más eficiente, de todos modos hay algunas reglas y prácticas que podemos adoptar para facilitar la vida de otros desarrolladores. 


Unicorn Tip

Puede comenzar haciendo que su código sea legible con pequeños pasos y no tiene que ser solo en proyectos nuevos. Uno de los pasos iniciales que puede realizar es crear estándares de código y reglas para desarrolladores. No es necesario que cambie todo el código a la vez, puede comenzar cambiando los nombres de las variables, dividiendo una función que sea un poco grande y eliminando las variables no utilizadas.


Los pequeños pasos que puede seguir para mejorar su código son los siguientes:

 

Llama a las Cosas por su Nombre

 

Si después de 2 semanas de nombrar una variable o función no recuerda su significado. Debe considerar cambiarlo por un nombre significativo, más fácil de entender. Tres cosas que te ayudarán con eso:

Primero, el nombre debe representar el tipo de intención, el nombre debe responder a las siguientes preguntas:

  • ¿Por qué existe?
  • ¿Qué hace?
  • ¿Cómo se usa?

«Si un nombre requiere un comentario, entonces el nombre no revela su intención».

Mira esta parte del código:

 

Lo que hace que este código sea un poco difícil de entender al principio no es la complejidad en sí mismo, sino el mal uso de los “naming” o mala denominación. El código en sí no expresa lo que hace o tal vez cómo usaría la pila.

 

Veamos una definición de nomenclatura más significativa:

Otros puntos importantes son:

  • Evite el uso de abreviaturas, incluso cuando el nombre sea un poco largo.
  • Usa nombres pronunciables

 

Uso de Comentarios

 

Intenta explicarte en tu código, en lugar de escribir toneladas de comentarios. Alguien me dijo una vez: “El código es como un libro, debes escribir de manera coherente, limpia y elegante”.

Sin embargo, en ciertos casos, es necesario escribir algunos comentarios, algunos de ellos pueden ser:

  • Comentarios legales
  • Comentarios informativos.
  • “TODO” comentarios

Algunos ejemplos:

Uso de las Regiones

Hay tantas opiniones sobre el uso de regiones en su código c #, en lugar de ser categórico, le daré algunos ejemplos de usos y precauciones que puede tener en cuenta al usar regiones.

Buenos y malos Usos:

 

Buen uso:

Puedes utilizar regiones para estandarizar su código; en algunas empresas, existen algunas reglas sobre la denominación o la estructura de las clases. Un ejemplo de buen uso de regiones:

En este ejemplo, estoy usando regiones para definir la estructura de la prueba unitaria a seguir en todas ellas, esto hace que sea más fácil encontrar y comprender cualquier parte de mi prueba unitaria para todos. Y es una guía a futuro para otros desarrolladores de cómo deberían estructurar sus pruebas unitarias.

 

Malos Usos: 

 

«Las regiones no hacen que una clase de 800 u 8000 líneas sean menos horribles y tétricas de lo que serían sin regiones».

  • No la uses para ocultar grandes bloques de código en regiones, en lugar de refactorizarlos y considerar cómo se podría mejorar su estructura.
  • Recuerde el principio SOLID de responsabilidad única o “single responsability”: No se debe dividir un método usando regiones porque su método hace cosas diferentes, si ese es el caso, refactorice su código para aplicar este principio.

Al final del camino esto nos lleva a una conclusión, hacer tus métodos cortos, consisos que sigan el principio de una sola responsabilidad hace que tu codigo mantenible a lo largo del tiempo y nos permite crear unit test de una manera sencilla y elegante.

 

Conclusiones

 

  • El código limpio es un viaje continuo que nos lleva a una mejor versión de nuestro código. En entornos productivos es difícil mantener el código limpio, pero no es imposible.
  • Los hábitos de Code review y las reglas del desarrollador son imprescindibles para un buen trabajo en equipo.
  • Parte de esta información está basada en el libro  Clean code book, super recomendado si quieres seguir mejorando la calidad de tu código.

Referencias: