El arte de nombrar: por qué el naming es filosofía aplicada

Hay una vieja broma en el 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, pero la verdad está en el segundo problema. Nombrar bien es difícil porque no es una tarea de estilo. Es una decisión sobre qué es cada cosa.

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 que haces al nombrar se propaga: todo el que lea ese nombre pensará dentro de la frontera que tú trazaste, aunque la frontera 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 van a heredar sin darse cuenta.

Frege: sentido y referencia

Gottlob Frege distinguió entre la referencia de un nombre (a qué apunta) y su sentido (cómo lo presenta). “El lucero del alba” y “el lucero de la tarde” apuntan al mismo planeta, Venus, pero lo presentan de forma distinta.

En el código pasa igual. getUser() y fetchAccount() pueden devolver el mismo registro de la misma tabla —misma referencia— y sin embargo cuentan historias distintas sobre para qué sirve ese dato. El sentido importa tanto como la referencia, porque el sentido es lo que el próximo developer va a creer.

Un nombre miente cuando su sentido no coincide con lo que la función realmente hace. validate() que además guarda en base de datos no es un nombre pobre: es un nombre mentiroso.

Wittgenstein: el significado es el uso

El segundo Wittgenstein desmontó la idea de que las palabras tienen un significado fijo pegado detrás. El significado de una palabra, dijo, es su uso dentro de una práctica.

Aplicado al código: un nombre no significa lo que dice el diccionario ni lo que tú tenías en la cabeza al escribirlo. Significa cómo se usa en las cien llamadas repartidas por el proyecto. Si count a veces es un total y a veces es un índice, su significado real es la confusión que provoca, no la intención con la que lo bautizaste.

De ahí una regla honesta: el nombre lo valida quien lo lee, no quien lo escribe. Si hay que abrir la implementación para saber qué guarda una variable, el nombre ya falló, por elegante que parezca.

Nombrar es la última fase del entender

Aquí está la parte incómoda. Cuando no encuentras un buen nombre, casi nunca es un problema de vocabulario. Es que todavía no entiendes bien qué es esa cosa.

El nombre esquivo es un síntoma. data, info, manager, helper, process, handle —los nombres genéricos son el residuo de un concepto que no acabaste de pensar. Ponerles nombre concreto te obliga a decidir qué son, 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.

Por eso nombrar bien no se hace al final, como quien pinta la pared. Se hace pensando, y el buen nombre suele llegar a la vez que la buena estructura. Si el nombre no sale, no es que te falte creatividad: es que el problema aún no está resuelto.

Reglas prácticas que uso

• Nombra por lo que es, no por cómo se implementa. orderedItems sobrevive a un cambio de estructura; arrayList muere con él.
• Un nombre, un concepto. Si la misma palabra significa dos cosas en dos módulos, tienes dos conceptos disfrazados de uno.
• 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 el criterio va a morir. 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.

Por qué me importa tanto

Escribí filosofía antes de escribir código, y el puente entre las dos disciplinas es exactamente este: el lenguaje no describe el mundo, lo recorta. Elegir una palabra es elegir qué distinciones vas a ver y cuáles vas a volver invisibles.

Un programa es, en el fondo, 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 los nombres mienten, cada línea que se apoya en ellos hereda la mentira.

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.