La legibilidad es escribir código para que otros lo entiendan

En ocasiones me han preguntado por qué insisto tanto en que el código que se escriba sea lo más legible posible, que se pueda leer y entender sin que construcciones extrañas o clases de cientos de líneas te arañen la vista, por poner unos ejemplos.

Se pueden dar muchos argumentos a favor de añadir un poco de esfuerzo a nuestro trabajo para escribir código que otros puedan entender; de todos los posibles a mí me parece que hay un criterio fundamental que no siempre se tiene tan en cuenta.

Cualquier trozo de código va a ser muchas veces leído que escrito o modificado. Esto es, cualquier método, función, clase, etc. va a ser repasado y leído en más ocasiones que las veces que hay que ir a ellos para hacer una pequeña modificación. Por tanto, si a todas esas veces le añadimos un coste de tiempo por la complejidad de entender lo que leemos estamos ante un obstáculo que nos quitará tiempo para dedicarnos a tareas más productivas o creativas.

No escribimos software para nosotros sino para que otros lo entiendan. Esto es clave para conseguir soluciones mantenibles y evolucionables. A veces ignoramos que ese otro podemos ser nosotros mismos.

¿He mencionado un extra de esfuerzo?. En realidad ese esfuerzo lo tenemos que hacer explícitamente si no estamos acostumbrados a fluir con los buenos hábitos de programación que existen para este tema en particular; elemenos tan sencillos y triviales como elegir buenos nombres descriptivos para nuestros artefactos de software (¿por qué llamar a una variable _nde cuando le podemos poner _numeroDeEntidades, por ejemplo), métodos o funciones que hacen una única cosa sin más de tres o cuatro argumentos, elementos de una clase ordenados siempre de la misma manera en toda la solución y un larguísimo y extenso etcétera.

Soy de la opinión de que quien no intenta escribir legiblemente realmente no le interesa hacer un buen trabajo y está dejando piedras en el camino con el que un compañero se tropezará cuando tenga que asumir ese código.

Lo sorprendente es que muchas veces el esfuerzo de escribir algo de manera complicada ¡es el mismo que escribirla de manera simple!. Si tenemos las dos opciones, ¿por qué entonces no hacer la que supone un mejor trabajo?.