Menos verde y rojo; más azul y negro

Un título un poco capcioso, debo reconocerlo. Se trata de la configuración de colores que suelo usar en los editores de texto. Reminiscencia de épocas pasadas. Para lograr un punto intermedio, podría mencionar la equivalencia de github en su tema claro, el cual sería menos gris y azul; más rojo y morado.

En este artículo pretendo expresar mi opinión acerca del impacto negativo de tener una gran cantidad de “verdes” y “rojos” en tu código fuente, los cuales explicaré a continuación.

Verde: comentarios

Este punto no requiere mucho desarrollo. Es ampliamente sabido que un código con exceso de comentarios denota:

  1. Falta de conocimiento del programador sobre lo que está haciendo, ó
  2. Resignación a que el código que ha escrito no es claro ni para él ni para nadie.

Desde luego que existen comentarios útiles o incluso necesarios. Personalmente me gusta dejar una referencia a un enlace de documentación oficial cuando estoy implementado una integración con un servicio externo, de manera de generar un “puente” entre “nuestro código” y el contrato externo, de manera de que el próximo programador tenga un fácil acceso a la misma y pueda determinar si ese contrato sigue siendo válido, o si fue correctamente interpretado. También hay anotaciones que son necesarias para el correcto funcionamiento de nuestro sistema; nada podemos hacer contra ellas. Y desde luego hay casos de ciertos lenguajes antiguos cuya naturaleza impide en muchos casos poder lograr un código lo suficientemente autodescriptivo (no, no es el caso de POO o el paradigma funcional). Me refiero a los comentarios que explican aquello que el código debería ser capaz de expresar y no lo está haciendo.

Don’t comment bad code. Rewrite it - Brian W. Kernighan

Rojo: cadenas de texto

Según mi entender existen dos usos para las cadenas de texto:

  1. definir un mensaje que deberá ser entregado a algún destino, como la respuesta al usuario o un almacén de datos o servicio externo, y
  2. definir un valor de estado.

Para el primer caso, entiendo que en nuestro mundo globalizado actual deberíamos diseñar nuestros sistemas para que sean “internacionalizables”; esto es, definir las cadenas de texto para cada idioma en un origen común y utilizar claves para acceder a los mismos. Si bien en muchos casos estas claves serán también cadenas de texto, estaremos reduciendo la “verbosidad” de texto en nuestro código. En el segundo caso, tratándose de valores de estado, deberíamos buscar minimizar el margen de error al tipear un valor de forma incorrecta, pudiendo reemplazar estos valores por constantes.

Azul y negro: código

Habiendo satisfecho los dos puntos anteriores, deberíamos ver ahora una base de código con.. bueno.. más código. Y el lector se preguntará qué beneficio ha logrado, por lo que indicaré algunos además de los antes descritos:

  1. Legibilidad: nuestro cerebro se basa en abstracciones para poder comprender un estímulo. El código que leemos es el estímulo. Con abstracción no me refiero a imaginar, sino a colocar una pieza de información dentro de una “caja” cuya única información que nos interesa es su entrada y su salida (abstraernos de ella). De ahí el por qué utilizamos modularización (clases, funciones, librerías) para escribir código, además de propiciar la reusabilidad claro. Lograr una base de código con la menor cantidad de ruido posible facilita nuestra comprensión del mismo.
  2. Organización: disponiendo de un lugar común para definir cierto tipo de información permite saber de antemano a dónde ir a buscar algo, lo cual reduce la curva de aprendizaje.
  3. Dejar lugar para lo que realmente importa: cuando escribimos código, lo que en realidad estamos haciendo (por si aún no lo has aprendido, cosa que dudo) es definir las reglas de nuestro negocio. Y esto es lo que importa: que nuestro código describa de forma lo más clara posible qué es lo que el negocio hace. Esto es importante no sólo para la organización “de grano fino” como es escribir un par de archivos de texto, sino además al momento de tomar decisiones de diseño globales. Debería ser la naturaleza de nuestro negocio la que defina nuestra arquitectura y no nuestro deseo personal de someter a prueba un modelo de moda. Negocio pequeño, solución pequeña; negocio complejo, soluciones complejas. pero eso será tema de otro artículo.