Entendiendo código ajeno

Supongo que a todos los que estudiamos o han estudiado informática les habrá tocado alguna vez intentar entender un código no escrito por ellos. Normalmente si es un código escrito por profesores suele estar bien escrito e indentado, con sus correspondientes comentarios, etc. Todo lo necesario para que el alumno pueda entenderlo más o menos bien. Sin embargo, si es un código con propósito no docente entenderlo suele costar bastante más, normalmente por la falta de documentación (comentarios y/u otros documentos auxiliares) y porque no todos tenemos el mismo estilo de programación. No incluyo aquí otros factores como la diferencia de lenguajes de programación y similares porque ya estaríamos entrando en otro orden de cosas.

El problema viene cuando intentas entender un código tal que dada su dimensión ha tenido que ser descompuesto en nueve (9) directorios diferentes, sobre algo que todavía no manejas del todo bien y además sin un maldito comentario en todo el código. Bueno, corrijo, a veces me encuentro algún comentario de explicación de los parámetros de entrada y salida de algunas funciones concebido para una posterior generación de documentación con el Doxygen, pero totalmente incompletos. Obviamente no diré quién ha programado este código, y si algún lector lo sabe porque se lo he dicho personalmente agradeceré que no lo diga en los comentarios, pero sí es cierto que en los últimos días me estoy acordando bastante de esa persona.

A todo esto, yo propongo una solución (modo irónico ON). Que si el compilador detecta que el código sobrepasa un cierto umbral de líneas de código no genere el ejecutable si un cierto porcentaje de las líneas (bastante bajo, tampoco es cuestión de forzar al personal) no son comentarios. No es tan difícil comentar qué significa cada uno de los atributos de una clase, qué hace una función o el por qué de sus parámetros. Y luego ya los profanos en el código agradeceríamos muchísimo comentarios un poco más profundos sobre las partes no evidentes del código, pero eso ya a gusto del programador, que parece que para algunos esto ya sería desviarse demasiado de la programación del algoritmo o lo que sea que estén programando (tal vez el "hola mundo" en Visual Basic) y ser demasiado condescendientes para con los posibles lectores del código (modo irónico OFF).

En mi opinión, un buen programador no es sólo el que hace código eficiente, que funcione de la hostia y que aplique propiedades como la reusabilidad y similares, sino aquel que es capaz de escribir algo que pueda entenderse fácilmente, obviamente sin renunciar a lo anterior. Estoy seguro de que esto podría aumentar la eficiencia en el desarrollo de código y evitar a los programadores que vengan detrás horas (y palabrotas varias) innecesarias a la hora de entenderlo. He dicho.