Estilos de nombres y convenciones explicados
Los nombres en el código, los archivos, las URL y los títulos siguen convenciones que cambian de un lenguaje y formato a otro. Esta guía recoge los estilos más comunes, dónde se espera cada uno y los detalles que más confunden: siglas, números, títulos y letras fuera del inglés.
Los estilos más comunes
| Estilo | Ejemplo | Cómo se forma |
|---|---|---|
| camelCase | orderTotal | Primera palabra en minúscula, las siguientes con mayúscula inicial, sin separador |
| PascalCase | OrderTotal | Todas las palabras con mayúscula inicial, sin separador |
| snake_case | order_total | Minúsculas, palabras unidas con _ |
| CONSTANT_CASE | ORDER_TOTAL | Mayúsculas, palabras unidas con _ |
| kebab-case | order-total | Minúsculas, palabras unidas con - |
| dot.case | order.total | Minúsculas, palabras unidas con . |
| Title Case | Order Total | Palabras separadas por espacios, cada una con mayúscula inicial |
| Sentence case | Order total | Solo la primera palabra con mayúscula inicial |
A camelCase a veces se le llama lower camel case y a PascalCase upper camel case. CONSTANT_CASE también se conoce como screaming snake case.
Qué estilo espera cada lenguaje y formato
La mayoría de los ecosistemas fijaron una convención hace tiempo, y seguirla hace el código más fácil de leer para cualquiera que conozca ese ecosistema:
| Dónde | Convención habitual |
|---|---|
| JavaScript, TypeScript, Java | camelCase para variables y funciones, PascalCase para clases, CONSTANT_CASE para constantes fijas |
| Python (PEP 8) | snake_case para funciones y variables, PascalCase para clases, CONSTANT_CASE para constantes |
| C# | PascalCase para tipos, métodos y miembros públicos; camelCase para variables locales y parámetros |
| Go | PascalCase exporta un nombre fuera de su paquete; camelCase lo mantiene privado |
| Ruby, Rust | snake_case para métodos y variables, PascalCase para tipos |
| CSS y HTML | kebab-case para propiedades, nombres de clase y atributos data- |
| URL | kebab-case; Google recomienda guiones en lugar de guiones bajos entre palabras |
| Tablas y columnas SQL | snake_case, porque muchas bases de datos pasan los nombres sin comillas a una sola caja |
| Variables de entorno | CONSTANT_CASE, como DATABASE_URL |
| Claves de configuración | dot.case para ajustes anidados, como server.port |
| API JSON | No hay una regla única: muchas usan camelCase y otras snake_case; sigue la API con la que trabajes |
kebab-case no se puede usar en nombres de variables en la mayoría de los lenguajes de programación, porque el guion se lee como signo menos: order-total significa order menos total.
Siglas y números
Las siglas son donde más discrepan las convenciones. Una escuela las mantiene en mayúsculas (userID, parseHTML); otra las trata como palabras normales (userId, parseHtml). Las guías de estilo de Java y JavaScript de Google siguen la segunda opción, que mantiene claros los límites entre palabras cuando se juntan siglas: XmlHttpRequest es más fácil de dividir que XMLHTTPRequest. Las pautas de .NET de Microsoft mantienen en mayúsculas las siglas de dos letras (IOStream) y solo ponen en mayúscula la primera letra de las más largas (HtmlButton). La API del navegador XMLHttpRequest mezcla ambas, por eso se cita a menudo como advertencia.
Los números no tienen mayúsculas ni minúsculas, así que un conversor no puede saber si utf8Decoder significa «utf8 decoder» o «utf 8 decoder». Los conversores suelen unir el número a la palabra anterior. Elige una grafía y úsala en todas partes.
Title Case y Sentence case en los títulos
En los títulos en inglés, las guías de estilo no ponen mayúsculas a todas las palabras de la misma forma. Los estilos AP y Chicago dejan en minúscula artículos, conjunciones y preposiciones cortas salvo al principio o al final («The Lord of the Rings») y difieren en la lista exacta. Muchas guías de interfaces y documentación, incluidas las de documentación para desarrolladores de Microsoft y Google, usan en cambio Sentence case («Change your password»), que es más fácil de aplicar con coherencia y suena menos formal.
El Title Case del conversor de LeedyBox pone en mayúscula todas las palabras, lo que va bien para etiquetas y nombres tipo variable, pero no para un titular de estilo periodístico: baja a minúscula las palabras cortas a mano después.
Convertir entre estilos pierde información
Toda conversión primero divide un nombre en palabras, usando las mayúsculas y los separadores como pistas, y luego une las palabras en el nuevo estilo. Lo que el estilo de destino no puede expresar se pierde: parseHTML se convierte en parse_html, y al volver se obtiene parseHtml. También se eliminan los signos de puntuación, así que «don't» pasa a ser dos palabras.
Por eso conviene tratar un estilo como fuente de verdad. Si una base de datos usa snake_case y el código usa camelCase, convierte en la frontera cada vez, en la misma dirección, en lugar de guardar los nombres en ambas formas.
Renombrar claves entre una API y otra
Cuando un front-end en camelCase habla con un back-end en snake_case, la mayoría de las bibliotecas de serialización pueden asignar los nombres automáticamente, así que los datos nunca se renombran a mano. Convertir un documento JSON una vez, por ejemplo unos datos de prueba o una respuesta de ejemplo, es otra tarea, y el modo «Claves JSON» del conversor la hace sin tocar los valores.
Cuidado con las colisiones: user_name y userName se convierten en la misma clave en cualquiera de los dos estilos, y una sobrescribiría a la otra. Los símbolos iniciales como _id o $ref suelen tener significado para una base de datos o un esquema concretos, así que comprueba si se pueden renombrar.
Mayúsculas y minúsculas más allá del inglés
Las reglas de mayúsculas no son iguales en todos los idiomas. La ß alemana se convierte en SS en mayúscula, así que la palabra se alarga. El turco tiene una i con punto y otra sin punto: sus parejas en mayúscula son i → İ e ı → I, mientras que la regla predeterminada de la mayoría de los lenguajes de programación convierte i en I. toUpperCase() de JavaScript usa la regla predeterminada; toLocaleUpperCase('tr') aplica la turca. El coreano, el chino y el japonés no tienen mayúsculas ni minúsculas, así que solo cambian los separadores entre palabras.
Las mayúsculas también importan en los nombres de archivo. Windows y, por defecto, macOS tratan Readme.md y README.md como el mismo archivo, mientras que Linux los trata como dos. Un cambio de nombre que solo altera mayúsculas puede pasar desapercibido en un sistema y romper enlaces o importaciones en otro.
Preguntas frecuentes
¿Es mejor camelCase o snake_case?
Ninguno es mejor en general. Usa la convención del lenguaje, el framework o la API con que trabajas; la coherencia dentro de un mismo código importa más que la elección en sí.
¿Las URL deben usar guiones o guiones bajos?
Guiones. La guía de Google sobre URL recomienda guiones entre palabras, y los slugs en kebab-case como /case-converter/ son la práctica habitual en la web.
¿Por qué Git no detecta que solo cambié las mayúsculas de un nombre de archivo?
En un sistema de archivos que no distingue mayúsculas, Git suele tratar el nombre antiguo y el nuevo como el mismo archivo. Renombra con git mv, por ejemplo pasando por un nombre temporal, para que el cambio quede registrado en los sistemas donde las mayúsculas importan.
¿Cómo escribo una marca como iPhone o eBay en camelCase?
Los conversores dividen en las mayúsculas, así que esos nombres salen como palabras separadas. En el código suele ser más claro tratar la marca como una sola palabra (iphoneModel) y conservar su grafía oficial solo en el texto que leen las personas.