Escribiendo código limpio (parte 2)

Continuamos con la segunda parte de este articulo en el que comento algunos de los fundamentos básicos mas importantes del conocido libro "Clean Code" del gran Robert C. Martin.

Utiliza un formato único en tu código

Cualquier formato, por extraño que sea, es mejor que ninguno en absoluto. Dará coherencia y estructura al código, y unas pautas a seguir por todos los desarrolladores. Algunos de ellos ya los hemos mencionado, como el tamaño de las funcione y las clases.

Algunas otras cosas que puedes acordar:

¿Conoces la Ley de Demeter?

Lanza excepciones en lugar de devolver códigos de retorno

Este enfoque logra un doble beneficio:

Establece fronteras

Las fronteras nos permiten establecer límites claros entre nuestro código y aquel que no controlamos.

Hay muchos casos en los que no tenemos control directo sobre el código que ejecutamos, como cuando utilizamos librerías de terceros o frameworks.

Establecer estas fronteras nos ayuda a limitar la interacción con ese código externo, facilitando su sustitución si fuera necesario en el futuro. De esta manera, podemos minimizar el impacto de cambios o problemas en componentes que no controlamos.

Las fronteras también son útiles cuando trabajamos con código que aún no existe. Podemos definir interfaces que, de manera temporal, se implementen con datos simulados hasta que el código definitivo esté disponible.

Y así un largo etcétera. Cuando veas un conflicto en la forma de definir el formato de algo específico en vuestro equipo, lo mejor es definir una regla para que todo el mundo lo haga de la misma forma.

• Densidad vertical: los conceptos que están relacionados deberían aparecer juntos verticalmente. Necesitarás reglas que decidan cuándo se debe dejar una línea en blanco y cuándo no.

• Ubicación de los componentes: normalmente los campos de una clase se suelen poner al principio de la misma. También hay que decidir dónde situar las clases internas o las interfaces, en el caso de que permitáis usarlas.

• El número de caracteres por línea: Normalmente los editores vienen marcados con una línea vertical que suele rondar los 120 caracteres. Es una buena regla a seguir.

• Por un lado, no necesitas recordar manejar manualmente los códigos de error ni decidir qué acción tomar, ya que las excepciones lo harán por ti.

• Por otro lado, se logra una clara separación entre la lógica del "camino feliz" (el flujo normal) y la gestión de errores, que se maneja en los bloques `catch` correspondientes.

Lo ideal es crear excepciones personalizadas que aporten un significado más semántico al error, permitiendo identificarlo rápidamente, y acompañarlas de mensajes de error claros y descriptivos.

Escribe Test

Finalmente solo me queda comentarte, que si nunca habías aplicado los conceptos que te he comentado en estos dos artículos de la serie, no pierdas el tiempo y te pongas manos a la obra. Es posible que al principio te cueste hacerte con la rutina de aplicarlos, pero una vez le pilles el truco no sabrás vivir sin ellos, ademas de lograr que tu código sea más legible y más fácil de mantener.

Abstrae tus datos: no uses getters y setters indiscriminadamente

En lenguajes como Java, es muy común crear un objeto y, de inmediato, generar automáticamente todos sus getters y setters para acceder y modificar su estado.

Sin embargo, las clases existen para encapsular los datos y asegurar que solo puedan ser modificados desde el exterior bajo ciertas reglas que definimos. No queremos exponer los detalles internos de nuestros datos sin control.

Aquí es clave diferenciar si nuestra clase es una simple estructura de datos o un objeto con comportamiento. Los objetos ocultan sus datos mediante abstracciones y proporcionan funciones para operar con ellos. Por otro lado, las estructuras de datos exponen su contenido, pero sus funciones no realizan operaciones significativas.

En este último caso, sí puede tener sentido exponer todos sus atributos mediante getters y setters, o incluso hacerlos públicos.

La Ley de Demeter es un principio útil para detectar un alto acoplamiento en el código. Establece que un objeto no debería conocer los detalles internos de otros objetos con los que interactúa. Si necesitamos que un objeto realice una tarea, debemos solicitárselo directamente en lugar de navegar por su estructura interna.

Esta ley se refiere a situaciones como esta:

Este es el ultimo y la verdad es que no hay mucho misterio aquí: los test ayudan a definir y validar la funcionalidad del software que estás implementando.

Existen muchos enfoques y tipos de test, pero un buen punto de partida son los test unitarios. Estos son los más simples para comenzar y además, deberían representar la mayor proporción en un conjunto de pruebas. Son rápidos de ejecutar y validan los detalles específicos de nuestra implementación.

Dependiendo de varios aspectos, dentro del ciclo de vida del software de nuestro proyecto, después de los test unitarios, podríamos (deberíamos) implementar algún test de integración modular, de aplicativo y/o sistema, etc. podrá parecer excesivo, pero os aseguro que cualquier cosa que evite una vuelta atrás de nuestro artefacto, merece la pena ser implementada, sobre todo si el proyecto es grande y se realizan múltiples construcciones de forma paralela.

El problema con este tipo de código es doble. Primero, requiere un conocimiento profundo de la estructura de las clases para realizar una operación que debería ser sencilla desde el punto del código en el que estamos trabajando. Segundo, este código es muy susceptible a modificaciones, ya que depende de múltiples clases que pueden cambiar en cualquier momento.

La solución a la violación de esta ley generalmente implica reestructurar el código. No se trata solo de crear métodos que oculten el problema, sino de identificar claramente quién es responsable de cada acción y delegar esa responsabilidad de manera adecuada.