Concepto y contexto
Las convenciones de nombres convierten palabras en identificadores previsibles mediante reglas compartidas de mayúsculas, separadores y acrónimos.
No cambian el significado del dominio, pero reducen ambigüedad y facilitan leer código, API, archivos y esquemas.
Un buen modelo mental separa el concepto abstracto de su representación concreta y del entorno donde se utiliza. Esa separación evita trasladar automáticamente supuestos válidos en un protocolo, biblioteca o formato hacia sistemas que pueden aplicar reglas o garantías diferentes.
Fundamentos y terminología
camelCase empieza en minúscula y capitaliza palabras siguientes; PascalCase capitaliza también la primera; snake_case usa underscore; kebab-case usa guiones.
Cada plataforma impone restricciones, por lo que el guion encaja en URL pero no en muchos identificadores de lenguaje.
La terminología debe leerse junto con el estándar, versión o contrato que la define, porque palabras parecidas pueden describir propiedades distintas según la capa. Explicitar esas definiciones mejora interoperabilidad, documentación y capacidad para diagnosticar comportamientos inesperados.
Cómo funciona
Una conversión fiable identifica primero los límites de palabras y luego aplica la convención destino.
Acrónimos, números, Unicode e identificadores mixtos como HTTPServer2ID hacen que tokenizar sea más importante que sustituir separadores de forma ciega.
En sistemas reales conviene seguir el recorrido de los datos entre capas e identificar qué transformaciones son reversibles, cuáles introducen restricciones y dónde puede perderse información. Así resulta más sencillo razonar sobre responsabilidades entre productores, consumidores, almacenamiento y transporte.
Ejemplo razonado
userProfileId, UserProfileId, user_profile_id y user-profile-id pueden representar el mismo concepto en JavaScript, clases, SQL y rutas web.
Una política por capa suele ser mejor que imponer una convención única sobre ecosistemas con idiomas propios.
Un ejemplo razonado es reutilizable cuando muestra sus precondiciones e invariantes y no solo el resultado final. Cambiar un supuesto cada vez permite distinguir el comportamiento garantizado por un estándar de las decisiones particulares de una aplicación o implementación.
Errores y conceptos equivocados
Cambiar mayúsculas y minúsculas no equivale siempre a renombrar correctamente porque pueden perderse fronteras de palabra y algunas transformaciones Unicode dependen del idioma.
Los acrónimos también necesitan una regla estable, por ejemplo URLValue frente a UrlValue.
Muchos fallos nacen de supuestos implícitos entre sistemas aparentemente compatibles que usan versiones, reglas de canonicalización o modelos de tipos diferentes. En interoperabilidad y seguridad conviene especificar y probar entradas anómalas en lugar de tratarlas como casos irrelevantes.
Buenas prácticas y criterios de elección
Sigue convenciones nativas del ecosistema, documenta excepciones y define reglas para acrónimos, números y mappings entre API y base de datos.
Automatiza lint cuando sea posible, pero considera los cambios de nombres públicos o columnas persistentes como modificaciones de contrato.
Una práctica robusta combina estándares documentados, bibliotecas maduras, contratos explícitos y pruebas con casos límite representativos. La mejor elección no es siempre la más breve o popular: también cuentan portabilidad, legibilidad, rendimiento, seguridad, evolución y coste operativo.
