¡Hola Devs! Por Qué Nombrar Es El Problema Más Difícil del Software

Hay un chiste clásico: los dos problemas más difíciles de las ciencias de la computación son la invalidación de caché, nombrar cosas y los errores de off-by-one. Pero nombrar no es solo un chiste — es una fricción diaria que drena silenciosamente la productividad del equipo.

Cuando tu diseñador le dice "card", tu PM le dice "tile" y tu código le dice BoxContainer, ya perdiste. El lenguaje que usamos moldea cómo pensamos sobre el sistema, y nombres inconsistentes crean fragmentación de dialectos entre roles.

Esta guía desglosa enfoques probados para nombrar lo que los devs realmente nombran todos los días: design tokens, componentes de UI, clases CSS, features y variables. Cada sección apunta a un recurso concreto y probado que puedes guardar y usar de inmediato.

TL;DR: Los buenos nombres son cortos, lógicos, significativos, conocidos por todos y no atados a propiedades visuales. Los malos son o demasiado genéricos (container) o demasiado específicos (blueButtonLarge).

¡Vamos a darle al playbook práctico! 🚀

Designer sketching UI component naming taxonomy on whiteboard with sticky notes Coding Session Visual

Nombrando Design Tokens: Aprende de la Taxonomía de Intuit

Los design tokens son donde el caos de nomenclatura pega más fuerte — porque cruzan la frontera diseñador-dev. Intuit (la empresa detrás de Mailchimp, QuickBooks y TurboTax) construyó una taxonomía flexible de tokens que escala entre múltiples marcas y productos.

El Principio Central: Separa Responsabilidades por Capa

Un sistema de tokens robusto normalmente tiene cuatro capas:

Primitives  →  Semantics  →  Components  →  Pages
(valores)      (intención)   (contexto)     (uso)
  • Primitives: blue-500, space-4, radius-md — valores crudos, sin marca
  • Semantics: color-action-primary, space-inline-sm — basados en intención
  • Components: button-bg-hover, card-padding — alcance del componente
  • Pages: checkout-header-bg — overrides por página (úsalos con moderación)

El Variables Taxonomy Map de Vodafone UK

El equipo de design system de Vodafone UK publicó un Variables Taxonomy Map que visualiza cómo los tokens se conectan entre esas cuatro colecciones. El insight clave: solo por el nombre de un token, cualquier dev debe inferir dónde se usa y qué representa.

brand.color.primary
  └── primitives.color.blue.500
        └── semantics.color.action.primary
              └── components.button.background

Si puedes leer esa cadena y entender la intención al instante, tu taxonomía está funcionando.

Herramienta: Design Token Naming Guide

Romina Kavcic creó una guía + inventario de nombres que te ayuda a configurar tu propia estructura con componentes, categorías, estados y roles. La hoja de cálculo compañera te da una vista de pájaro de cada token, filtrable por tema y modo.

Tip de pro: Antes de inventar tu taxonomía, checa el trabajo fundamental de Nathan Curtis sobre naming de design tokens — la mayoría de los sistemas modernos se construyen sobre él.

Developer writing CSS class names and design token variables in code editor Development Concept Image

Nombrando Componentes de UI, Colores y Features

Componentes de UI: Compara Antes de Decidir

¿Atorado nombrando un componente? No inventes — compara. La Component Gallery de Iain Bean cataloga más de 50 componentes de UI (de accordion a visually-hidden) y lista los nombres alternativos que cada uno recibe en los principales design systems.

Esto resuelve el problema clásico: ¿es Toast, Snackbar, Notification o Alert? La galería te muestra cómo lo llaman Material, Carbon, Polaris y otros — así eliges el término más ampliamente entendido.

Para nombres específicos de comportamiento, namethatui.com es un diccionario visual de patrones comunes de UI.

Colores: Más de 30 Mil Nombres a Tu Alcance

David Aerne mantiene un repositorio con 30,355 nombres únicos de colores — sacados de referencias y miles de contribuciones de la comunidad. Viene con color picker y búsqueda por nombre. Cuando #FF6B6B necesita un nombre humano, ahí es donde miras.

Features: Nombra con la Boca del Usuario, No del Roadmap

La adopción de features falla cuando la descubribilidad falla. La guía práctica de Erin Gannon deja un punto cristalino: los buenos nombres de feature usan el lenguaje del propio usuario, no jerga interna.

La técnica:

  1. Pídele a 5 usuarios que expliquen la feature con sus propias palabras
  2. Extrae los sustantivos y verbos recurrentes
  3. Usa esas palabras como nombre de la feature

Ojo: No nombres features con nombres de equipo interno, codenames de sprint o abstracciones de ingeniería. Al usuario no le importa que internamente se llame "Proyecto Halcón".

Layers y Grupos: Consistencia Sobre Creatividad

Las buenas prácticas de nomenclatura de Javier Cuello para layers y grupos en Figma se resumen en cinco reglas:

ReglaBuenoMalo
Estructura lógicacard/header/titleTitle copy 2 final
Cortobtn-primaryprimary-button-large-blue
Significativonav-itemgroup-12
Conocido por todosavatarprofile-circle-img
No visualalert-errorred-box

Variables: El Naming Cheatsheet

Para variables a nivel de código, el naming-cheatsheet en GitHub es la referencia de facto. Su fórmula central:

[acción][contexto][objetivo]

Ejemplos:

  • getUserProfile (acción: get, contexto: User, objetivo: Profile)
  • isEmailValid (prefijo booleano + sujeto)
  • handleSubmitClick (patrón de event handler)

Anti-patrón: data, info, temp, value, obj — eso no son nombres, son placeholders fingiendo ser nombres.

Team collaborating on feature naming strategy with user feedback sticky notes IT Technology Image

La Conclusión: Los Nombres Son un Contrato de Equipo

El nombre correcto es el que es bien entendido y usado por el equipo y los usuarios. Todo lo demás es ruido.

Cuando la adopción está baja, antes de culpar a la feature, al onboarding o a la documentación — checa el nombre. Un nombre confuso es un impuesto que se paga en cada conversación, cada code review y cada ticket de soporte.

Referencia Rápida: Guárdalo Ya

Qué Hacer Ahora

  1. Audita tus nombres actuales. Corre un grep rápido por data, temp, box, container en tu codebase. Cada hit es un futuro punto de confusión.
  2. Elige una capa de taxonomía (ej: design tokens) y estandarízala este sprint. No intentes hervir el océano.
  3. Mete conflictos de nombre al backlog — no arregles todo de golpe, pero tampoco los olvides.

Para entender cómo la nomenclatura moldea la arquitectura de sistemas, échale un ojo a nuestro análisis sobre construir un flywheel de ASR clínico con skills de agentes de IA — donde la nomenclatura consistente entre pipelines de IA hizo la diferencia entre un sistema mantenible y una pesadilla de debug. Y si sigues cómo escala la nomenclatura de infraestructura en datacenters de la era de IA, nuestro breakdown de la integración de Azure con la plataforma NVIDIA Rubin muestra por qué las convenciones de nombre importan en cada capa del stack.

Fuente: Esta guía se basa en el artículo de Smashing Magazine How To Name Things, reorganizado para uso práctico enfocado en devs.

Nombrar es deporte de equipo. La mejor hora para arreglarlo fue al inicio del proyecto. La segunda mejor es ahora. 💪

Este contenido fue redactado con la asistencia de herramientas de IA, basándose en fuentes confiables, y fue revisado por nuestro equipo editorial antes de su publicación. No reemplaza el asesoramiento de un profesional especializado.