Elipsis y pleonasmo en programación

En lingüística, la elipsis se define como: «Omisión intencionada de algún elemento del discurso para suscitar determinados efectos en el lector», y un pleonasmo: «Añadir enfáticamente a una frase más palabras de las necesarias para su comprensión con el fin de embellecer o añadir expresividad a lo que se dice». Cuando escribimos código pueden surgir adjetivos similares, compacto y verboso, surgen como posibles alternativas; pero no siempre estas captan la estética del código.

Ejemplos de elipsis son: «Anoche compramos empanadas y cervezas también» (se omite el verbo «comprar»), «Las rosas son rojas, el cielo azul» (se omite el verbo «ser»), «Nunca fui bueno en los deportes, pero en leer sí» (se omite «fui bueno»); y de pleonasmo: «Subir arriba», «Especies diferentes», «Pero sin embargo».

Al mismo tiempo: si hacemos un experimento con código, ocurre lo siguiente. Supóngase que —en Python— escribimos:

triple_combination = []
for x in range(10):
  for y in range(10):
    for z in range(10):
      triple_combination.append((x, y, z))

Sería una construcción verbosa, pues se repiten varias veces palabras claves (for, in) y la invocación a una misma función (range(10)).

Una versión compacta puede ser:

[(x, y, z) for x in range(10) for y in range(10) for z in range(10)]

Sin embargo, si nos atendemos a la definición de elipsis y pleonasmo, ninguna logra capturar esa esencia, ni embellecen, ni suscitan efectos al lector. El primer ejemplo, verboso, no gana en belleza, y es cuestionable si gana en expresividad; el segundo, compacto, el único efecto que produce es confusión —«¿en qué orden se ejecuta cada for?»—. Casos similares ocurren en todos los lenguajes de programación.

Esta sería una reflexión sobre los límites de los lenguajes formales con respecto a los lenguajes naturales, en la búsqueda de hacer mejor código y ganar en calidad. Pues siempre se habla del caso inverso, no se programa en lenguajes naturales porque son ambiguos, por ello, usamos lenguajes formales, que acotan esas formas en estructuras sintácticas rígidas. Pero, esa rigidez afecta nuestra percepción de la estética del código, haciendo inevitable dos preguntas entrelazadas:

¿Cuándo cruzamos la línea de un código compacto y legible a uno confuso?

¿Cuándo cruzamos la línea de un código legible y expresivo a uno redundante y verboso?

Que conducen a una última —y más inquietante— pregunta:

¿El concepto de estética es aplicable al código?