Nota: Traducido de la versión original en Inglés.
Recuerdo que hace un par de años, mientras trabajaba con algunos desarrolladores, uno de ellos parecía irritado al ver líneas vacías en el código fuente. Creo que se perdia de una dimensión importante del software: Legibilidad. Toma un libro cercano. Adelante, hazlo. Toma cualquier libro cerca de ti. Ábrelo en cualquier página. ¿Hay espacios en blanco entre líneas? Si no tomaste un libro para niños, las líneas vacías emergerán como crack en los años 80, haciendo los párrafos más fáciles de leer (en lugar de enrojecerlos). Hablando del diablo…
Ahora me siento mejor*. Así como las líneas vacías dividen ideas en los libros de texto, las líneas vacías en el código fuente ofrecen una nueva dimensión para estructurar el código. Es como algo que el desarrollador quiere decir sobre el código. Casi como comunicación no verbal. Estoy exagerando, pero realmente, usa líneas vacías para separar líneas de código relacionadas cuando “extract method” llega al límite.
Un código perfectamente refactorizado tendrá solo una línea por método, lo cual es absolutamente un incremento muy grande en complejidad de detalle. ¡No olvides la complejidad de detalle! A veces estamos tan preocupados por minimizar la complejidad dinámica que terminamos agregando toneladas de complejidad de detalle. 100 métodos son más difíciles de leer que 20 métodos 5 veces más grandes si colocas adecuadamente líneas vacías.
Por cierto, presta atención a la semántica, usa las palabras más adecuadas para los identificadores y evita la notación húngara. Si necesitas una variable para almacenar la cantidad de intentos en que se realiza alguna acción, llámala attemptsCount (o algo similar con dos palabras), no uses cosas como ac, o simplemente count (¿conteo de qué?). Ahorrar algunos milisegundos en cada pulsación de tecla no es tan bueno como ahorrar dos o tres días de tiempo de desarrollo más dos o tres días de tiempo de depuración. Hagamos las cuentas solo por diversión. Cuando escribo attemptsCount me lleva como 2 o 3 veces más que count. Digamos 5 veces más. Si tenemos que escribir attemptsCount 1000 veces y cada vez toma 2 segundos, tenemos un total de 2000s (o 33 minutos). Si tenemos que escribir count 1000 veces y cada vez toma 0.4s (2s / 5) tomará un total de 400s (o 7 minutos). Ganancia total usando count: 26 minutos. Digamos media hora. Ahora, dependiendo del contexto, esto podría ser absolutamente nada o demasiado. ¿Estás contando solo una cosa en tu aplicación? Si es así, count está bien, pero apuesto a que si estás escribiendo count 1000 veces, estás contando más de una sola cosa. Entonces, attemptsCount parece ser más apropiado para aplicaciones reales. Deja que el código hable por sí mismo.
Y recuerda, no se trata solo de complejidad y semántica, que a su vez determinan la mantenibilidad. También se trata de escribir código que sea agradable de leer y bueno para los ojos de los programadores, si no eres como el mencionado compañero de trabajo, por supuesto. </rant>
* Por la línea en blanco, ¡no te equivoques! Me gusta mantener mis neuronas intactas… bueno, excepto por algunas cervezas de vez en cuando. Por cierto, las células cerebrales sí se regeneran y se reproducen, incluso después de la madurez. Gracias biólogos. Te amo, Viviana.