Introducción: Nombrar Es Comunicar
El código se lee mucho más de lo que se escribe. Las estimaciones varían, pero una cifra ampliamente citada de Clean Code de Robert C. Martin sitúa la proporción en aproximadamente 10:1 — por cada línea de código que escribes, diez desarrolladores la leerán durante la vida del proyecto. Esto significa que los nombres que eliges para variables, funciones, clases y archivos no son solo etiquetas para el compilador; son mensajes para cada futuro lector, incluyéndote a ti mismo dentro de seis meses.
Las convenciones de nombres — las reglas que gobiernan qué formato de mayúsculas usar y cuándo — son una de las decisiones más impactantes que un equipo puede tomar. El nombramiento consistente reduce la carga cognitiva, hace el código más fácil de buscar, previene errores causados por la sensibilidad a mayúsculas y señala profesionalismo en proyectos de código abierto. El nombramiento inconsistente, por otro lado, obliga a los lectores a cambiar constantemente de modelo mental: "¿Esto es una clase o una variable? ¿Una constante o una función? ¿Un miembro privado o una API pública?"
Esta guía recorre las principales convenciones de nombres, explica qué lenguajes usan qué formato, aborda la fricción que ocurre en los límites entre sistemas y ofrece consejos prácticos para su aplicación.
Los Cuatro Grandes: camelCase, PascalCase, snake_case, kebab-case
Casi todas las convenciones de nombres en la programación moderna se construyen sobre cuatro formatos principales. Aprender a reconocerlos de un vistazo es una habilidad fundamental:
- camelCase — las palabras se unen sin separador; cada palabra después de la primera se capitaliza:
getUserProfile,isEnabled,totalItemCount. La primera letra en minúscula te dice inmediatamente que es una variable o función, no un tipo. - PascalCase — idéntico a camelCase pero la primera letra también es mayúscula:
UserProfile,HttpClient,DatabaseConnection. La primera letra mayúscula universalmente señala una clase, interfaz, tipo o constructor. - snake_case — todo en minúsculas con guiones bajos entre palabras:
get_user_profile,is_enabled,total_item_count. Los guiones bajos crean límites visuales entre palabras similares al lenguaje natural, lo que muchos desarrolladores encuentran más legible que camelCase. - kebab-case — todo en minúsculas con guiones entre palabras:
get-user-profile,is-enabled,primary-button. No puede usarse como identificador en la mayoría de lenguajes (el guión es un operador de resta) pero es el estándar para CSS, atributos HTML, URLs y argumentos de CLI.
Un quinto formato, CONSTANT_CASE (todo mayúsculas con guiones bajos: MAX_RETRIES, API_BASE_URL), se usa universalmente para constantes en prácticamente todos los lenguajes.
Convenciones por Lenguaje: Quién Usa Qué
Cada comunidad de lenguaje de programación se ha asentado en convenciones específicas, a menudo codificadas en una guía de estilo oficial. Violar estas convenciones hace que tu código parezca ajeno para otros desarrolladores del ecosistema:
JavaScript / TypeScript
Variables y funciones usan camelCase: const userName = getUser(). Clases y componentes React usan PascalCase: class UserProfile, <NavBar />. Constantes usan CONSTANT_CASE: const MAX_RETRIES = 3. Los nombres de archivo para componentes usan PascalCase (UserProfile.tsx) o kebab-case (user-profile.tsx) según el proyecto. Las interfaces y tipos de TypeScript usan PascalCase: interface UserData.
Python
PEP 8 exige snake_case para variables, funciones y métodos: def get_user_profile(). Las clases usan PascalCase: class UserProfile. Las constantes usan CONSTANT_CASE: MAX_RETRIES = 3. Los miembros privados se prefijan con guión bajo: _internal_cache. Los módulos y paquetes usan nombres cortos en snake_case.
Java
Variables y métodos usan camelCase: getUserProfile(). Clases e interfaces usan PascalCase: class UserProfile implements Serializable. Constantes usan CONSTANT_CASE: static final int MAX_RETRIES = 3. Los paquetes usan todo en minúsculas con puntos: com.example.userprofile.
CSS
Las propiedades están definidas por la especificación en kebab-case: background-color, font-size. Los nombres de clases siguen el mismo patrón: .primary-button, .nav-bar. La metodología BEM extiende esto con dobles guiones bajos y dobles guiones: .card__header--highlighted.
Go
Go usa las mayúsculas como mecanismo de control de acceso. Los identificadores en PascalCase son exportados (públicos): func GetUser(). Los identificadores en camelCase son no exportados (privados): func getUser(). Esto lo aplica el compilador, no solo la convención. Los acrónimos se mantienen completamente en mayúsculas: HTTPClient, XMLParser, ID.
Rust
Variables y funciones usan snake_case: fn get_user_profile(). Tipos, traits y enums usan PascalCase: struct UserProfile. Constantes usan CONSTANT_CASE: const MAX_RETRIES: u32 = 3. El compilador de Rust emite advertencias por violaciones de convención de nombres, siendo uno de los lenguajes con aplicación más estricta.
Ruby
Variables y métodos usan snake_case: get_user_profile. Clases y módulos usan PascalCase: class UserProfile. Constantes usan CONSTANT_CASE o PascalCase. Los métodos predicado terminan con signo de interrogación: enabled?. Los métodos destructivos terminan con signo de exclamación: save!.
Cuando las Convenciones Colisionan: Límites de API
Los problemas de nombres más difíciles surgen donde dos sistemas con diferentes convenciones se encuentran. Estos límites son una fuente constante de confusión y errores:
APIs JSON: camelCase vs snake_case
Un frontend en JavaScript envía {"userName": "alice"} (camelCase) a un backend en Python que espera {"user_name": "alice"} (snake_case). Ambos equipos siguen las convenciones de su lenguaje, pero los datos deben transformarse en el límite. Las soluciones comunes incluyen bibliotecas de serialización que manejan la conversión automáticamente, o acordar un formato para el contrato de la API (camelCase es más común en APIs REST porque JSON es una notación de JavaScript).
Columnas de Base de Datos
SQL tradicionalmente usa snake_case para nombres de columnas (user_name, created_at), pero los ORMs los mapean a camelCase o PascalCase en el código de aplicación. Django convierte automáticamente a snake_case de Python. Sequelize puede configurarse con underscored: true. JPA usa anotaciones @Column(name = "user_name"). El principio clave: cada capa debe usar su propia convención y convertir en el límite.
CSS-en-JS
Las propiedades CSS son kebab-case (background-color), pero en objetos JavaScript deben ser camelCase (backgroundColor) porque los guiones no son válidos en identificadores JS. Cada biblioteca CSS-in-JS (styled-components, Emotion, utilidades de Tailwind) maneja esto automáticamente, pero los desarrolladores que escriben estilos inline deben recordar la conversión.
Conversión Automática de Formato en Serialización
La mayoría de los frameworks modernos proporcionan mecanismos integrados para convertir entre convenciones de nombres en los límites de serialización:
- Jackson (Java):
@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)convierte campos PascalCase o camelCase a snake_case en la salida JSON. - Pydantic (Python):
model_config = ConfigDict(alias_generator=to_camel)genera alias camelCase para campos snake_case, para que la API hable camelCase mientras el código Python mantiene su estilo. - Sequelize (Node.js):
underscored: trueen opciones del modelo mapea atributos camelCase a columnas snake_case. - Gson (Java):
FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORESserializa campos camelCase como snake_case. - System.Text.Json (.NET):
JsonNamingPolicy.SnakeCaseLowerconvierte propiedades PascalCase a snake_case.
Linting y Aplicación
Las convenciones solo son útiles cuando se aplican. Sin verificaciones automatizadas, la desviación en los nombres es inevitable a medida que los equipos crecen:
- ESLint (JavaScript/TypeScript): La regla
camelcaseaplica camelCase para variables. La regla@typescript-eslint/naming-conventionpermite control granular — reglas diferentes para variables, funciones, clases, interfaces y parámetros de tipo. - pylint / flake8 (Python): El checker
naming-conventionvalida el cumplimiento de PEP 8 para todos los tipos de identificadores. - RuboCop (Ruby): El departamento
Namingaplica las convenciones de la comunidad Ruby con reglas para nombres de métodos, variables, clases y constantes. - clippy (Rust): Integrado en la cadena de herramientas de Rust, advierte sobre violaciones de convención de nombres por defecto.
- golint / staticcheck (Go): Verifica las convenciones de nombres exportados y advierte si los acrónimos no están completamente en mayúsculas.
La mejor práctica es añadir reglas de nombres a tu pipeline de CI para que las violaciones se detecten antes de la revisión de código.
Refactorización de Nombres: Renombrar a Escala
- Refactorización de renombre del IDE (F2 en VS Code, Shift+F6 en IntelliJ) es el enfoque más seguro para identificadores individuales. Entiende el alcance y actualiza todas las referencias.
- grep/sed para cambios masivos es tentador pero peligroso. Un ingenuo
sed 's/user_name/userName/g'también transformará literales de cadena, comentarios y fragmentos de URL. Siempre revisa los diffs cuidadosamente. - Codemods basados en AST (jscodeshift para JavaScript, libcst para Python) entienden el árbol de sintaxis y solo renombran identificadores reales, no contenidos de cadenas.
- Herramientas de conversión como nuestro convertidor de mayúsculas son útiles para convertir listas de nombres extraídos de un código base — pega nombres de variables, conviértelos al formato objetivo y usa los resultados en tu script de refactorización.
Convenciones de Equipo: Documentar e Integrar
- Documenta en CONTRIBUTING.md o un STYLE_GUIDE.md dedicado. Lista la convención de nombres para cada construcción con ejemplos.
- Aplica en CI con reglas de linting. Si el pipeline de CI pasa, los nombres son correctos.
- Usa editor config:
.editorconfigy archivos de configuración específicos del lenguaje aseguran que el editor de cada desarrollador aplique las mismas reglas. - Incluye en la incorporación: Los nuevos desarrolladores deberían aprender las convenciones el primer día.
- Revisa y actualiza: Las convenciones deben evolucionar. Si una regla causa fricción, discútela como equipo y actualiza la guía.
Casos Especiales
Acrónimos: XMLParser vs XmlParser
Una de las preguntas de nombres más debatidas. La guía de Java de Google trata los acrónimos como palabras: XmlParser, HttpClient. La guía de C# de Microsoft preserva acrónimos de dos letras pero pone en minúsculas los más largos: IOStream pero HtmlParser. Go capitaliza todos los acrónimos: HTTPClient, XMLParser. El mejor consejo: elige una regla, documéntala y aplícala. La consistencia importa más que qué regla elijas.
Variables de Una Letra
Los nombres de una letra como i, j, k para contadores de bucle y x, y para coordenadas son ampliamente aceptados por convención. Más allá de estas convenciones establecidas, prefiere nombres descriptivos: userIndex sobre u.
Notación Húngara (Legacy)
Prefijar nombres de variables con abreviaturas de tipo (strName, intCount, bIsEnabled) era común en C y programación temprana de Windows. Ahora se considera un antipatrón en la mayoría de lenguajes porque los editores modernos muestran información de tipo al pasar el cursor.
Nuestro Convertidor para Conversiones Rápidas
Cuando trabajas entre límites de lenguajes, refactorizas código o limpias datos, el convertidor de mayúsculas puede ahorrarte tiempo significativo. Pega una lista de nombres de variables en cualquier formato y conviértelos todos a tu convención objetivo al instante. La herramienta soporta 17 formatos incluyendo todas las convenciones discutidas en este artículo.
Para operaciones por lotes, la función de subida de archivos maneja archivos .txt, .csv y .json directamente. Los encabezados CSV pueden convertirse independientemente de los datos de las celdas, y las claves JSON se convierten recursivamente preservando los valores. El modo multi-línea permite aplicar diferentes formatos a líneas individuales. Todo se ejecuta en tu navegador sin comunicación con servidores, haciéndolo seguro para código propietario y datos confidenciales.