Mi cruzada contra los comentarios en el código

Los que me conocéis sabéis que soy un rabioso defensor de mis principios, lo cual no quiere decir que mis ideas estén escritas a fuego, dicho sea de paso.

Lo que me trae por aquí hoy es algo que me toca especialmente las narices: Los comentarios en el código.

Lo reconozco, al principio era un ávido comentador de código. Ponía todo bonito para que un posible lector lo tuviera todo desmenuzado “al detal”  y no sufriera un derrame al ver mis (horribles) algoritmos de decodificación de bitmaps por la época en la que programaba en C++ con un compilador de Watcom y me lo pasaba teta haciendo scroll parallax en modo 13h y editores de mapas a base de tiles.

Vale, todo eso estuvo gracioso… para empezar. Uno se vuelve pragmático con los años, o por lo menos en algunos aspectos, y deja paulatinamente de chorrear comentarios por todos sitos. Finalmente, después de varios años te encuentras con un librete escrito por un tío canoso y que hace bastante que hizo la comunión: El Tío Bob, ¡el tío Bob Martin!

Lo que me llamó la atención fue que muchas de las cosas que decían era puras corroboraciones de mis sospechas. Una de las sospechas que ya intuía y que resulta más “revolucionaria” era la relacionada con los comentarios de código.

Decidí hacerle caso: ni un comentario de código. La máxima era que el código se “leyese”, que tuviera una capacidad expresiva tal que hiciese innecesario añadir nada más.

¿Y adivináis qué? A día de hoy los comentarios en el código me echan para atrás casi tanto como un método de 5 parámetros. Me repugnan, me hacen daño, me queman las córneas, me producen una profunda repulsa, asco, depresión. Me dan ganas de coger una heavy machine gun del Metal Slug y reventar el código a balazos.

Imagen// This is a useful comment, I promise!

Mi reacción puede ser exagerada, sí, pero no sabéis lo que toca las pelotas el pu** StyleCop de los co**nes con la documentación. StyleCop puede ser una herramienta excelente o una pesadilla. En mi caso estoy al borde de pegarle fuego.

Y ahora bien, ¿cuál es el porqué mi posición? Aparte de lo expuesto en el párrafo anterior y de modo más general, estas son mis razones para eliminar todo vestigio de comentario en el código.

  1. Ruido. Producen ruido. MUCHO RUIDO. Ver código con todo comentado es simple y llanamente un despropósito. Una clase desnuda escrita bajo los preceptos del Código Limpio es todo lo que necesito ver. Lo demás es broza. Mierda. ¿Para qué quiero ver una jodida propiedad cuyo comentario es “// Gets or sets the name”? Os lo diré: para que en vez de ver chicha, vea una obviedad.
  2. Mienten. Van a desincronizarse sí o sí. El código subyacente y sus comentarios acabarán diciendo cosas distintas, si no dicen la contraria. No me va a convencer nadie: los comentarios engañan bastante más habitualmente de lo que sería deseable. Mantener en sincronía los comentarios con el código es una tarea inútil. Una pérdida de tiempo. La única fuente de verdad en una aplicación es el código: lo que ejecuta.
  3. Inexpresividad. Tener que comentar el código significa que piensas que no es suficientemente claro. Escribir código que no es claro, legible y expresivo no es para lo que estamos aquí, ¿o no? El código debe hablar, ¡conyo! Lo demás es una guarrada.
  4. Pesados. Pesados de escribir y como dije antes de mantener. El coste es tremendo. Eliminate the waste!
  5. Interrumpen. ¿Hay algo que descentre más a un desarrollador que tener que comentar método, propiedad, clase…? más aún cuando está diseñando un sistema en pleno crecimiento, donde van y vienen clases, se eliminan, crean, renombran elementos. Si ya es molesto en un sistema en mantenimiento, cuando se trata de un sistema de este tipo es equivalente a construir una casita de madera encima de un géiser de Yellowstone.
  6. El ojo se acostumbra. Finalmente, somos seres humanos y destacamos por nuestra habilidad innata para discriminar datos irrelevantes. Terminan siendo parte del paisaje y los ignoramos por completo. ¿Utilidad? Ninguna.

Son un lastre.

Por todo esto y mucho más, ardan los comentarios en el infierno.

¿Pero qué cojones es el modelo?

Chavalada, en mi poco tiempo en esto del desarrollo os digo que pocas cosas tengo tan seguras como lo que voy a decir a continuación: el modelo no es una jodida base de datos. Una base de datos NUNCA puede ser el modelo. De hecho, decir que el modelo es una base de datos es la misma aberración que decir que un modelo es un XML, un CSV o un archivo de texto.

El modelo es pura abstracción: no hay sistema operativo, ni frameworks, ni tablas. Insisto, ¡NO HAY TABLAS!

El modelo no son los trazos que representan el número 8, sino el número como abstracción. Es algo conceptual, puro, casi etéreo y sagrado. Decir que el modelo es la BBDD es casi un insulto. ¿Tan poco valoras tu dominio para casarlo con una representación determinada, que para colmo siempre se acaba traduciendo en palabras como “tabla”, “fila”, “columna? La entidad, el concepto… lo es todo.

Ensuciarlo con terminología de bases de datos solamente denota una falta de visión del dominio. Hay gente se empeña en ver claves ajenas, inner joins, consultas de consultas, procedimientos almacenados… Todo eso está muy bien, pero no dejan de ser trazos, un bitmap, un dibujo del número 8, no el número en sí mismo.

Habrá gente que me diga que me pongo filosófico respecto al tema (como es costumbre en mí), que no hace falta ser tan extremista con el tema y que en el fondo nos basta con pensar que la base de datos es un modelo válido. Es cierto que normalmente una base de datos puede representar con cierta fidelidad un dominio, pero no deja de ser eso: una representación.

La programación como arte que evoluciona tiende a ser cada vez más cercana al dominio. Hay muchos patrones arquitecturales que hablan directamente de “Modelo”. MVC, MVP, MVVM… es un hecho que trabajar cerca del modelo tiene unas ventajas (obvias). De ahí mi gusto por DDD. Por el contrario, trabajar sin un modelo suficientemente refinado y lejos del ruido de las tecnologías subyacentes tiene innumerables inconvenientes.

Conozco casos en los que se ha usado un XML como modelo. ¿Os podéis imaginar lo que pasó? Mierda, mierda y más mierda. Aplicaciones imposibles de modificar, acoplamiento infinito.

Tenemos que alejarnos de eso. Una BBDD tanto si es relacional como si no, es tan solo una manera de almacenar datos con cierta estructura. Otra cosa es que haya aún demasiada gente que ha estado tan apegada a SQL que no sepa ver más allá de filas, columnas y selects.

The Managers Theory

It’s enounced by someone called “Suppa JMN” and states the following:

The code quality in a project is proportional to the number of total lines and inversely proportional to the product of the squared average of net lines of code by the number of classes named with the “Manager” suffix.

Capture

Where:

  • N is the net lines of the project.
  • M is the number of Managers.
  • c is the net lines of code of a class (measured as average).

The following list illustrates the measurement:

  • > 10. Code of extreme quality. Congratulations.
  • 2 – 10. Code of good mother.
  • 1 – 2. Average quality code.
  • 0,5 – 1. Mediocre code
  • 0,1 – 0,5. Turd.
  • < 0,1. A shit the size of a piano. Burn the repository now.