Ir al contenido

Líneas vacías y semántica en código fuente

·542 palabras·3 mins
Programación
Alejandro Duarte
Autor
Alejandro Duarte
Alejandro Duarte es un Ingeniero de Software, escritor publicado y galardonado. Actualmente, trabaja para MariaDB plc como Ingeniero de Relaciones con Desarrolladores (Developer Relations Engineer). Comenzó su trayectoria en programación a los 13 años con BASIC en una rudimentaria pantalla negra, para lugo rápidamente transitar a C, C++ y Java durante sus años académicos en la Universidad Nacional de Colombia. Trasladándose primero al Reino Unido y luego a Finlandia, Alejandro profundizó su participación en la comunidad de código abierto. Es reconocido en los círculos de Java, acreditado con artículos y videos que acumulan millones de vistas, y presentaciones en eventos internacionales.

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.

Relacionados

Enterprise App ahora disponible con Maven
·55 palabras·1 min
Vaadin UI Noticias
Nota: Traducido de la versión original en Inglés. ¡Finalmente! He logrado escribir un POM de Maven para Enterprise App.
Una estrategia para gestionar tablas SQL grandes
·420 palabras·2 mins
SQL Bases de Datos
Nota: Traducido de la versión original en Inglés. Hace unos meses, me involucré en un proyecto donde necesitaba generar reportes bastante grandes (más de 1 millón de filas) extraídos principalmente de una tabla SQL que crecía a un ritmo muy rápido.
Paginación: Una solución antigua de la web 1.0
·398 palabras·2 mins
UI
Nota: Traducido de la versión original en Inglés. Hace unos días, un usuario de Enterprise App me preguntó si la carga diferida (lazy loading) es mejor (particularmente en una aplicación de negocios) que la paginación.