La claridad es la cortesía del buen programador

El filósofo español, José Ortega y Gasset, dijo: «la claridad es la cortesía del filósofo», y que apela a que se pueden plantear cuestiones importantes en filosofía sin caer en un lenguaje oscuro, intrincado, que admite una falsa sofisticación y oculto detrás de una máscara de «profundidad». Algo similar ocurre con la programación.

A mí me gusta la claridad: partiendo porque no trabajo en un sótano sin ver la luz natural. (Aunque alguna vez sí lo hice.) Este estereotipo del informático, más que ser falso, también encuentra una realidad. Y es que, aunque se niegue —hoy más que antes—, es una actividad que incentiva el enfoque y a «perderse en tu propio mundo», luego, lo otro no es extraño. Pero la claridad del entorno de trabajo es exigua e irrelevante comparada con la forma de escribir código.

Son tantos los que creen —por buenas y malas razones—que crear complicadas soluciones de software son la mejor respuesta a un problema. Aunque lo nieguen. En algunas situaciones acaso no hay otra alternativa, en la mayoría, solo esconde una falta de generosidad hacia los demás —y hacia sí mismo— oculta por una incapacidad. Esto es, una incapacidad que surge por no ver una solución más simple de escribir y de entender. Y es que hacer claro algo oscuro no resulta fácil; si lo es hacer oscuro algo claro.

Cualquier persona que haya escrito código sabe que un problema tiene más de una solución. Algunas son más elegantes que otras, más compactas que otras. Incluso solo mejorando el nombre de las variables y de las funciones se puede hacer más legible un código. Sin embargo hacer código que funcione en desmedro de la claridad siempre encuentra más adeptos, más aplausos y ciertas satisfacciones.

La industria del software no es la misma de finales del siglo XX, ahora, todo debe ser rápido y presupone dinamismo, estar atento a los cambios: que vendrán inexorablemente. La renuncia de los programadores a la reflexión y a pensar se hace evidente con la frase: mientras funcione todo vale.

Esta concepción causa un enorme daño, sobre todo, en las industrias masivas y no criticas (entiéndase por «crítica» las empresas que desarrollan software donde los errores pueden incluso matar a personas [aunque eso no supone que no ocurra]). Una industria masiva como los software de facturación —por decir algo aburrido— son un lugar donde se pueden acumular capas y capas de complejidad dentro de un código que solo lo entienden un par de personas.

Yo he conocido a esas personas que llegan a la empresa con una túnica roja, pero sin corona; a la espera de que sus súbditos lo suban en brazos a un pulpito imaginario para que nos den la buena nueva. Escondidos detrás del conocimiento que solo ellos retienen de su software, todo cambio, debe pasar por su aprobación. Y los jefes están obligados a tratar de retenerlos en cada nuevo berrinche. (Quizá de las pocas cosas positivas de las metodologías ágiles es buscar evitar crear a estos personajes.)

La claridad en el desarrollo de software debe ser una aspiración, nunca una promesa resuelta. Una búsqueda. Una buena intención. Un anhelo. Pero nunca una renuncia. Porque la complejidad embriaga y es adicta (al igual que la soledad), y el desarrollo de software debe buscar reducir la complejidad: comenzar por ser claros es un buen primer paso.

---

Comencé hablando de un filósofo y me gustaría terminar con otro: Bertrand Russell, es un caso de filósofo que escribe con claridad (aunque eso no supone trivialidad). Un buen comienzo y, a su vez, divertido es su obra Historia de la Filosofía Occidental.¹

1. En español se encuentra publicada por la editorial Austral en dos tomos.