Cuando reviso código: arte y matemáticas

Cuando toca terminar un trabajo colaborativo, lo normal es revisar el código ajeno antes de dar una etapa por terminada, y tal como suele suceder con el testing, es algo que no todo el mundo se toma bien. Por regla general, yo hago una división de las cosas que me llaman la atención al revisar y las clasifico en dos categorías: arte y matemáticas.

Arte: me hizo mucha gracia cuando escuché hablar a Linus Torvalds en TED, pues parece que tengo algunas cosas en común con este señor cuyo trabajo admiro. Entre otras muchas cosas, hablaba del “código hecho con buen gusto”, y si bien estoy de acuerdo con él, esto es algo que entra en el terreno de la opinión. El resultado de ambos fragmentos de código que muestra es el mismo, pero cualquier persona, aunque no tenga ni idea de programación, puede notar a simple vista que uno tiene mas líneas que el otro. ¿Significa uno que está mal? Para nada, pues el resultado del proceso es exactamente el mismo, pero es innegable que cualquier persona tarda menos en leer el que tiene menos líneas, lo que lo hace mas eficiente, y por lo tanto “es de mejor gusto”. Así que de aquí, en todo caso, pueden surgir unas sugerencias o recomendaciones.

Estos casos pueden ser considerados por muchas personas como manías o petty hates de algunos programadores, que generalmente están ahí por motivos que no pueden parecer claros a simple vista (eficiencia, seguridad, mutabilidad del contenido, reusabilidad, facilidad de serialización…). Reconozco abiertamente que tengo bastantes: aborrezco la clase Vector de Java y el uso de tablas, cosa que no tiene nada de incorrecto y puede ser muy rápida e intuitiva, pero pueden generar a la larga una gran cantidad de problemas al ser objetos mutables, es decir, que tienen un acceso directo al contenido todo el tiempo en lugar de generar copias al pasar el parámetro, lo que significa que a la mínima que alguien se descuide, se puede acabar escribiendo simultáneamente desde dos lugares diferentes del código (lo que llamamos concurrencia) cuando no debería ser así, obteniendo resultados incorrectos en múltiples lugares. Esa situación no tiene por qué suceder si trabaja con cuidado, pero si se trabaja con un elemento de Collection simplemente ese problema no te pasa por diseño… e incluso puede resultar mas eficiente.

En resumen, es como preguntar, ¿prefieres el estilo barroco o el neoclásico? Pues en general yo prefiero la simplicidad a tener que limpiar todos esos recobecos, pero cuando se trata de generar código ofuscado para que no lo entienda nadie probablemente tenga sentido hacerlo espantoso.

Matemáticas: esta es la categoría en la que defenderé mi opinión con uñas y dientes: cuando se encuentra algo que simplemente está mal: un conjunto con los elementos [1, 2, 3] no es lo mismo que un conjunto que contiene [1, 2]. No es una cuestión de opinión sobre si el código me parece mas bonito o feo, sino de que el resultado no es el que se pedía. Están los casos de despiste, que le pasan a cualquiera, y los casos de errores de diseño que surgen cuando, al atacar los síntomas de un problema en lugar de la causa de la enfermedad directamente, estamos generando muchos mas problemas en otro lugar, además de permitir que dicha situación se replique en otro lugar. El retrabajo es inevitable cuando sucede esto, se moleste quien se moleste.

¿Las matemáticas pueden ser artísticas? Claro que sí, una buena implementación puede ser bonita de ver, y es algo a lo que se debería aspirar, pero hay que diferenciar entre la parte subjetiva y la objetiva al revisar.