Nombrar las cosas correctamente, de manera completa y clara, es una parte fundamental para escribir buen código. Aunque muchos desarrolladores encuentran esta tarea difícil y tienden a caer en trampas comunes que afectan la calidad y mantenibilidad de sus programas.
La buena noticia es que nombrar bien es fácil, siempre que evitemos algunos errores típicos.
En este artículo exploramos por qué cuesta tanto poner buenos nombres y ofrecemos consejos prácticos para hacerlo bien.
Nueve razones por las que se nombran mal las cosas
1. Suponer que todos saben lo que tú sabes
Un error común es creer que otros desarrolladores entienden las abreviaturas o nombres que para ti son obvios.
Por ejemplo, nombrar una variable como EmpNo pensando que todos sabrán que significa “EmployeeNumber” y que representa un identificador único en la base de datos.
La realidad es que puede confundirse con un número de empleado para login u otro dato distinto.
La solución es clara: llama a las cosas por lo que realmente son, incluso si el nombre es largo. Por ejemplo, EmployeeUniqueIDInDatabase es extenso, pero nadie lo confundirá.
2. El significado se desvía con el tiempo
A veces, un nombre empieza siendo preciso pero luego el código cambia y ese nombre ya no describe bien la función.
Por ejemplo, un método llamado SaveReceipt que primero guardaba un recibo en base de datos, pero luego también imprime el recibo.
En ese caso, un nombre más claro y específico como SaveReceiptToTheDatabase ayuda a evitar confusiones futuras.
3. Pereza
Nombrar bien requiere algo de reflexión, y algunos desarrolladores no quieren dedicarle tiempo. Usar variables con una sola letra (salvo excepciones como i para índices) es un mal hábito.
Dedicar unos segundos a pensar en qué es realmente esa variable y nombrarla acorde reduce errores y facilita la lectura.
4. Abreviar demasiado rápido
Abreviar por ahorrar tiempo puede ser contraproducente. La mayoría de los entornos de desarrollo modernos autocompletan nombres largos, así que no hay razón para usar acctBlnc en vez de accountBalance.
Además, ¿de quién es ese balance? ¿De la empresa? ¿Del cliente? Los nombres claros evitan estas dudas.
5. Olvidar que las funciones son verbos
Las funciones y métodos deberían nombrarse con verbos que describan qué hacen. getCustomer es un buen comienzo, pero ¿qué cliente se obtiene y de dónde? Mejor getCustomerInstanceFromDatabase es más descriptivo y claro.
6. Inconsistencia
Es importante usar los mismos términos para referirse a la misma cosa en todo el código. Si decides llamar “Customer” a una persona que compra en el sistema, no uses “Client” o “Buyer” en otros módulos. La inconsistencia genera confusión.
7. Nombres negativos
Evita nombres negativos en booleanos, como isNotValid o denyAccess, que dificultan la lectura y comprensión. Por ejemplo, en lugar de if (!isNotValid), usa nombres positivos para hacer el código más intuitivo.
8. Prefijos innecesarios
La notación húngara (usar prefijos que indican tipo o rol, como l para locales o a para argumentos) ha quedado en desuso. Los nombres deberían ser suficientemente claros por sí solos.
Si un método es tan complejo que necesitas prefijos para entender las variables, es mejor refactorizar.
9. Palabras vacías o “blancas”
Evita usar palabras sin significado claro como Helper, Handler, Service, Util, Process, Info, Data, Task, Stuff, o Object. Estas palabras no aportan información y sólo llenan los nombres sin propósito.
Nombrar es fácil si evitas hacer mal las cosas
Nombrar bien no es cuestión de talento especial, sino de disciplina y sentido común.
Evitar los errores anteriores reduce la carga cognitiva y facilita que otros desarrolladores (o tú mismo en el futuro) entiendan, mantengan y amplíen el código sin confusión ni errores.
En resumen, dedica un momento a pensar y escribe nombres claros, completos y descriptivos.
Como dice un famoso dicho parafraseado: “Nombra las cosas como si quien mantuviera tu código fuera un psicópata privado de sueño que sabe dónde vives”.