El arte de nombrar: un nombre lo juzga quien lo usa

El informe mensual daba doscientos catorce clientes. Facturación daba ciento noventa. Nadie había tocado los números y los dos venían de la misma base de datos.

La palabra cliente significaba dos cosas. En el CRM era todo el que había dejado sus datos alguna vez. En facturación era el que tenía al menos una factura emitida. Ninguna de las dos definiciones estaba mal. Lo que estaba mal era que compartieran nombre, porque el nombre compartido hizo creer durante dos años que se hablaba de lo mismo, y las reuniones en las que se decidía sobre «los clientes» decidían sobre dos poblaciones distintas según quién hubiera traído el informe.

Hay una broma vieja del gremio: solo hay dos problemas difíciles en programación, la invalidación de caché, nombrar las cosas y los errores por uno. La gracia está en el error de conteo. La verdad está en el segundo.

Nombrar es trazar una frontera

Cuando llamas usuario a algo estás afirmando que eso es un usuario, y no una cuenta, ni un perfil, ni una sesión, ni un contacto. La palabra recorta el mundo. Y el corte se propaga: todo el que lea ese nombre pensará dentro de la frontera que trazaste, aunque estuviera mal puesta.

Por eso un mal nombre no es un problema cosmético. Es una hipótesis falsa incrustada en el código, que otros heredan sin enterarse de que la están heredando.

La discusión tiene un diálogo entero dedicado

Platón le dedicó al asunto un texto completo, el Crátilo, y lo montó como una discusión entre dos posiciones que cualquiera reconoce hoy sin haberlo leído.

Hermógenes sostiene que los nombres son cuestión de acuerdo. Ninguno es más correcto que otro por naturaleza; lo que convengamos en llamar algo, eso es. Y si mañana cambiamos de idea, cambiamos el nombre y no ha pasado nada. Es exactamente lo que dice quien zanja una revisión con «es solo un nombre, ya lo renombramos luego».

Crátilo sostiene lo contrario: hay un nombre correcto para cada cosa, un nombre que le pertenece, y lo demás son ruidos. Es exactamente lo que le pasa a quien lleva veinte minutos parado delante de una variable buscando la palabra exacta como si existiera una sola y estuviera escondida.

Sócrates los deja mal a los dos, y lo interesante es cómo.

A Hermógenes le responde que un nombre es una herramienta —sirve para enseñar algo a alguien y para separar unas cosas de otras—, y que las herramientas no son indiferentes. Una lanzadera de telar sirve para separar los hilos; puedes hacerla de la forma que quieras, pero no de cualquier forma, porque hay formas con las que no se puede tejer. El acuerdo no basta: si el nombre no separa lo que tiene que separar, no vale, por mucho que estemos todos de acuerdo en usarlo.

A Crátilo le responde algo más incómodo. Si los nombres fueran correctos por naturaleza, no podría haber ningún nombre equivocado —lo mal nombrado sería, sencillamente, no nombrado— y eso es falso, porque la gente se equivoca al nombrar todos los días. Los nombres los pusieron unos primeros nombradores que también podían equivocarse. De donde sale la conclusión que cierra el diálogo y que debería ir enmarcada en cualquier equipo: es mejor aprender las cosas por las cosas mismas que por sus nombres.

Traducido al oficio: no aprendas el sistema leyendo sus identificadores. Los puso alguien que estaba entendiéndolo mientras los escribía, y estudiar sus nombres es heredar sus errores en el mismo paquete que sus aciertos, sin marca que los distinga.

Quién valida un nombre

Del argumento de la lanzadera sale la regla más útil que conozco sobre esto.

Sócrates pregunta quién juzga si una lanzadera está bien hecha, y la respuesta no es el carpintero que la fabricó: es el tejedor que la usa. El que hace la herramienta sabe cómo la hizo; solo el que la usa sabe si sirve.

Con los nombres pasa igual, y es demoledor para quien escribe. El nombre lo valida quien lo lee, no quien lo pone. Si hay que abrir la implementación para saber qué contiene una variable, el nombre ya falló, por elegante que le pareciera a su autor y por buenas que fueran sus razones. El autor tenía todo el contexto en la cabeza cuando eligió la palabra; ese contexto no viaja con el código.

De ahí que la revisión sea el único sitio donde un nombre se puede juzgar de verdad, y que «no entiendo qué es esto» sea información técnica y no una queja.

Pródico y el oficio de distinguir palabras

De entre los sofistas hubo uno, Pródico de Ceos, especializado en algo que sus contemporáneos encontraban ridículo: separar palabras que parecen sinónimas. Distinguía «alegrarse» de «disfrutar», «querer» de «desear», «valentía» de «audacia». Platón se ríe de él más de una vez, y la broma se entiende: visto desde fuera, parece un hombre gastando su vida en matices.

Es el mismo trabajo que consiste en decidir si cliente, cuenta, contacto y usuario son cuatro cosas o una con cuatro disfraces. Y produce la misma cara en la reunión —alguien discutiendo de palabras mientras hay cosas que hacer— hasta el mes en que el informe da doscientos catorce y facturación da ciento noventa.

Ahí se ve lo que Pródico defendía y sus contemporáneos no: que dos palabras que se usan como si fueran una acaban tapando que hay dos cosas distintas debajo. La distinción no se inventa al hacerla explícita. Ya estaba ahí, operando y cobrando, solo que sin nombre.

Nombrar es la última fase del entender

Aquí está la parte que más me ha costado aceptar. Cuando no encuentro un buen nombre, casi nunca es un problema de vocabulario. Es que todavía no entiendo bien qué es esa cosa.

El nombre esquivo es un síntoma. data, info, manager, helper, process, handle son el residuo de un concepto que no se acabó de pensar. Obligarse a un nombre concreto obliga a decidir qué es, y a veces esa decisión revela que el diseño estaba mal partido: que ese manager hacía tres cosas que deberían vivir en tres sitios y que ninguna de las tres tenía nombre porque ninguna de las tres se había visto por separado.

Por eso nombrar no se hace al final, como quien pinta la pared cuando ya está todo levantado. El buen nombre suele llegar a la vez que la buena estructura, y si no llega, lo que falta no es creatividad: es entender el problema.

Reglas que uso

• Nombra por lo que es, no por cómo está hecho. pedidosOrdenados sobrevive a un cambio de estructura; arrayPedidos muere con él.
• Un nombre, un concepto. Si la misma palabra significa dos cosas en dos módulos, tienes dos conceptos disfrazados de uno, y tarde o temprano alguien los sumará.
• La longitud paga si la vida es larga. Una variable de tres líneas puede llamarse i. Un concepto de dominio que se lee cien veces merece que lo escribas entero.
• Desconfía de los nombres cómodos. utils, common, misc son cajones donde va a morir el criterio. Lo que no sabes dónde poner es lo que aún no entiendes.
• Léelo en voz alta. Si al pronunciar la llamada la frase no tiene sentido en un idioma humano, el nombre miente en alguna parte.
• Escribe la definición en una línea. Si no cabe, o lleva un «y» en medio, no es un concepto: son dos.

Por qué me importa tanto

Un programa es una teoría sobre un trozo del mundo escrita en nombres. Si los nombres son honestos, la teoría se puede leer, discutir y corregir. Si mienten, cada línea que se apoya en ellos hereda la mentira sin saberlo, y el error no aparece en ningún test porque no es un error de cálculo: es un error de reparto del mundo.

El Crátilo no cierra la discusión, y probablemente por eso sigue leyéndose. Deja algo mejor que una respuesta: que los nombres no son ni sagrados ni indiferentes. Son herramientas hechas por alguien que podía equivocarse, y se juzgan por si sirven para separar lo que hay que separar.

Nombrar bien no es cosmética. Es la forma más barata de pensar con claridad, y la única que además se queda escrita.