Programadores del siglo XXI

He leído esto (http://blog.ivangadea.com/2009/02/27/management-del-siglo-xx/) que me ha recordado el eterno debate:

Me considero una persona tolerante a las ideas de los demás, pero hay una cosa que nunca he entendido completamente.

En determinadas escuelas de informática se ha instaurado la manía de meter líneas y separar el código de una manera artificiosa... con este me refiero a, por ejemplo, usar doble espaciado en el código y entre bloque y bloque de código poner una separación de 3 líneas y 6 cuando los bloques están en grupos separados. Ya no digo nada de los comentarios, siempre con bloques bonitos de varias líneas de /*** ... *** . . . *** ... ***/

Más allá de que al leer el artículo de management halla encontrado una razón más -que ya sospechaba- para este tipo de comportamiento a la hora de picar código, entiendo que halla gente que lo considere más bonito y claro.

Sin embargo personalmente soy de los que opino que el código, sin pasarse, cuanto más condensado mejor: no es lo mismo tener que analizar un bloque de código que ocupa 3 o más pantallas que uno que se puede ver en su conjunto sin tener que subir y bajar o imprimir en papel todo. Si a esto sumamos que, por suerte, la mayoría de los editores de código tienen resaltado de sintaxis con color, y que existen los comentarios // de final de línea...

Además NO todo el código es igual de complejo: ya sabemos esas zonas que deben estar super-optimizadas porque el 90% la CPU se lo pasará en ellas, o bien esas que tienen la operación más enrebesada. Yo soy firme defensor de la indentación adaptativa... hay zonas del código que en 2 segundos cualquiera reconocería, y otras que podemos estar todo el día sin saber que hacen a ciencia cierta. Lógicamente estas últimas zonas deberían llevar un formateado y unos comentarios mucho más completos y claros que las otras.

Es como quien para optimizar el código optimiza a diestro y siniestro, cuando normalmente basta con aplicar optimizaciones a 3 o 4 zonas claves y/o al flujo lógico del código para lograr un 95% de la posible optimización y el 5% restante ya son chorradas en las que el tiempo invertido apenas tendría resultados reales.

Es un punto de vista, supongo que habrá otros.