Sobre un libro de programación que no deseo hablar

Hoy me enteré de que, en la cafetería que visito cada día, han subido el volumen de la música de ambiente (¿Jazz?) —de modo deliberado— para evitar que la gente se dedique a conversar por teléfono o incluso gritar. (Esto me lo alertó un espía que frecuenta la cafetería al igual que yo, que, por casualidad, resulta ser también un informático.) Me parece una medida acaso efectiva, pero que no deja de ser molesta. Sobre todo para mí que soy susceptible al ruido. Una vez más mis auriculares con cancelación de ruido me han salvado.

Este evento adverso se pudo transformar en algo positivo. O al menos no prestarle atención. En los libros de programación ocurre lo mismo.

Hay lecturas que regalan una enseñanza, otras que olvidamos, y otras que necesitamos transformar por nuestro bien. La primera es la mejor, la segunda es irrelevante, luego la última presenta un reto. Esta final merece algunas palabras.

En programación, al menos, entre las perjudiciales —y que requieren un trabajo de transformación de nuestra parte— tenemos los libros que son técnico-morales. En otras palabras, libros que nos tratan de dar una versión final de las cosas, un cómo se debe hacer, sin matices ni flexibilidad, pero con mucha vanidad. Todo está cerrado como un puzzle que acabamos de completar. No hay posibilidad de cambio. No hay más piezas que añadir.

El autor con su gran sabiduría cree haber encontrado la verdad del desarrollo de software, y carente de humildad nos intenta influir con sus conocimientos.

Pero más que evitar su lectura, recomiendo leerlos. Pues en ellos hay algo interesante y es que, a pesar de estar sesgados en muchos aspectos, nos dan una forma de ver el desarrollo de software de una persona que tiene varios años de experiencia. ¿Algo podemos rescatar, no?

Yo, hoy, creo que sí.¹ Es como leer el diario de vida de una persona: hay cosas positivas y otras que jamás haremos, pero que, no obstante, nos da algunas enseñanzas (incluso de manera inversa, sobre lo qué no hay que hacer).²

A continuación le recomiendo un libro que cabe transformar:

Su título original, Clean Code (2008), es acaso unos de los libros más controvertidos de los últimos años. Amado por algunos, odiados por otros cuantos. Y es que el «tío Martin» nos presenta un conjunto de buenas prácticas para la programación, en particular, para lenguajes orientados a objetos.

Al igual que Rambo, recoge su granada de mano y metralleta y va al combate, a luchar contra todo un ejército, lo que, para nuestra sorpresa, sobrevive y vence a todos los «chicos malos». Nada mal. Luego de esa proeza, sube a un pulpito a compartirnos sus consejos. ¡Cuán absurda influencia puede generar un libro!

No me malinterprete, no lo considero un mal libro, más bien, un libro que hay que leer con cautela. Transformarlo.

Considere por ejemplo el capítulo 5, Formatting, Martin, nos presenta algunas formas correctas de formatear nuestro código, de manera vertical y horizontal, incluso termina el capítulo con las Uncle Bob’ Formatting Rules que, nos hacen presagiar, la necesidad de ver sus reglas en acción (y con su nombre, por supuesto). Una falta de modestia muy evidente. Si es cierto que el formateo del código es importante: es más importante en lenguajes como Java (lenguaje usado en el libro y verboso por naturaleza) que en otros como Python. Estas reglas que están tan ligadas a un lenguaje y que no presenta una contraposición son, para mí, demasiado estricta y poco generales. Nada de eso menciona el autor.

Mas no es extraño que el libro esté plagado de «Don’t»; «haga esto»; y «NO haga esto».

Antes bien, no quiero parecer injusto. Hay cosas positivas en Clean Code, por ejemplo…

¡Claro!, el capítulo 4, Comments, es para mí uno de los mejores, pues Martin hace un tratamiento no cerrado de sus reglas y que, dado el tema en cuestión, no es posible ser particular. Ya que todos los lenguajes de programación se pueden añadir comentarios. Definir qué es un mal comentario es como decir «este mensaje de WhatsApp que me enviaron es innecesario y este no», advertirlo y mostrarlo con ejemplos está muy bien.

Un ejemplo de comentarios innecesarios:

countries = [] # variable de países
def is_country(text):
   # función que valida un país
   return text in countries

Los dos comentarios carecen de utilidad porque son demasiado obvios, pues el código ya te entrega suficiente información: el nombre de la variable y el nombre de la función. Sumado a que es poco código, no es necesario escribir un comentario.

Los comentarios deben ser un apoyo al código, esto es, cuando hay varias variables o varias invocaciones a funciones en juego. En dicho caso podría ayudar alguna asistencia a la persona que revisa el código.

Un buen lector de libros de programación debe ser capaz de percatarse de esos detalles. Saber diferenciar cuando estamos frente a buenas prácticas, principios, reglas, que son particulares o aspiran a ser expansibles.

Aquel buen libro de programación debe buscar ser dinámico, flexible, abierto, general, para poder abarcar lo máximo posible teniendo en cuenta en que estamos en un ecosistema rico de tecnologías.³

---

Para finalizar una recomendación del primer grupo: libros que nos enseñan e indagan en la generalidad de la programación:

(Sus autores, Kernighan y Pike, son ampliamente conocidos, ambos fueron parte del equipo que desarrollo UNIX, en los Laboratorios Bell.)

1. Algunos nos ablandamos con la edad: eso me lo dijo un nefasto.

2. Recomiendo leer diarios, incluso más, escribirlo. Uno siempre se encuentra con más de una sorpresa.

3. Tenga en cuenta que digo «libro de programación», no un libro de «una herramienta de programación». Para este último caso está bien ser específico.