Respuesta rápida: el lenguaje y el proyecto deciden la convención
No existe una regla universal que obligue a escribir todas las variables en camelCase, todas las clases en PascalCase o todas las constantes en CONSTANT_CASE. La caja es parte exacta del identificador y la convención depende del lenguaje, del ecosistema y de las normas del proyecto. En Python, por ejemplo, PEP 8 recomienda snake_case para funciones y variables y CapWords para clases; en las directrices de .NET, los tipos y métodos públicos suelen usar PascalCasing y los parámetros, camelCasing.
La decisión segura consiste en consultar primero la guía oficial del lenguaje o framework, observar el código existente y aplicar una convención de forma coherente. Un conversor puede preparar nombres nuevos, pero no puede saber si APIClient, apiClient o api_client es la forma exigida por tu base de código.
Tabla de decisión orientativa
| Elemento | Convención frecuente | Ejemplo | Qué comprobar |
|---|---|---|---|
| Variable local | camelCase o snake_case | totalItems, total_items | Lenguaje y estilo del repositorio. |
| Función o método | camelCase, snake_case o PascalCase | loadUser, load_user, LoadUser | API pública, framework y convenciones del entorno. |
| Clase o tipo | PascalCase | InvoiceParser | Acrónimos, nombres del dominio y guía oficial. |
| Constante | CONSTANT_CASE o la convención del lenguaje | MAX_RETRIES | Que sea realmente constante y no una variable común. |
| Propiedad JSON | La definida por el contrato | user_id o userId | Compatibilidad con clientes y datos existentes. |
| Clase CSS | Nombre descriptivo, a menudo con guiones | account-summary | Metodología y estilos ya implantados. |
La tabla resume patrones habituales, no reglas lingüísticas. Un identificador externo —una clave JSON, un campo de base de datos, una variable de entorno o un parámetro de una API— puede formar parte de un contrato. Cambiar su caja sin coordinar consumidores y migraciones puede romper el sistema aunque el nuevo nombre parezca más elegante.
Variables y parámetros: nombres legibles, no frases decorativas
Las variables representan datos y conviene nombrarlas según su función: invoiceTotal, invoice_total o la forma equivalente exigida por el proyecto. Evitá convertir una oración completa sin revisar el resultado. Un nombre como data puede ser demasiado genérico, mientras que uno excesivamente largo puede ocultar la idea principal.
En lenguajes sensibles a mayúsculas, userId y userID son identificadores distintos. No los alternes dentro del mismo módulo. También evitá crear nombres que se distingan únicamente por la caja, porque dificultan la lectura y pueden ser incompatibles con herramientas o lenguajes que no distinguen esos nombres de la misma manera.
Funciones y métodos: la acción debe reconocerse
Una función suele beneficiarse de un verbo claro: calculateTotal, calculate_total o CalculateTotal, según la convención aplicable. No traduzcas ni capitalices mecánicamente nombres que forman parte de una API pública. Si cambiás getUser por GetUser, no estás corrigiendo ortografía: estás renombrando un símbolo y deberás actualizar llamadas, documentación, pruebas y posibles consumidores externos.
Los métodos especiales, callbacks y nombres impuestos por un framework conservan su grafía exacta. La uniformidad visual no justifica alterar connectedCallback, __init__ o una función requerida por una interfaz. Primero distinguí los nombres que controlás de los que pertenecen a una especificación.
Clases, tipos e interfaces
PascalCase es frecuente en nombres de clases y tipos porque marca con claridad el comienzo de cada componente: PaymentRequest, CsvReader. Sin embargo, la forma de las siglas varía entre estilos. Un proyecto puede preferir HttpClient y otro conservar HTTPClient. La mejor decisión no surge de una regla general, sino de la guía del ecosistema y de la consistencia con los símbolos vecinos.
En .NET, las directrices públicas utilizan PascalCasing para espacios de nombres, tipos, métodos, propiedades y eventos, y camelCasing para parámetros. En Java, la guía de Google emplea UpperCamelCase para nombres de clase. Estas coincidencias no convierten PascalCase en una obligación para todos los lenguajes ni para todos los elementos.
Constantes: la caja no convierte una variable en constante
MAX_RETRIES comunica visualmente una constante en Python y en muchos proyectos JavaScript, pero escribir una variable en mayúsculas no modifica su comportamiento. La inmutabilidad depende del lenguaje y de la declaración. Del mismo modo, una constante puede seguir otra convención en un framework o API concreta.
Antes de aplicar CONSTANT_CASE, verificá si el valor es realmente estable, si se exporta, si forma parte de un contrato y si el proyecto ya usa ese patrón. Mezclar maxRetries, MAX_RETRIES y MaxRetries para el mismo tipo de elemento obliga a memorizar excepciones y reduce la capacidad de localizar símbolos.
Propiedades JSON, bases de datos y variables de entorno
Una propiedad como customer_id puede pertenecer a una respuesta pública. Convertirla a customerId dentro de la documentación sin transformar también el dato crea un ejemplo falso. Cuando una aplicación necesita otra convención, utilizá una capa de mapeo explícita y documentá la frontera entre el formato externo y el interno.
Las variables de entorno suelen aparecer en mayúsculas con guiones bajos, por ejemplo DATABASE_URL, pero ese patrón tampoco debe imponerse a campos de formulario ni a texto visible. Las claves de configuración, las columnas y los identificadores técnicos deben copiarse exactamente cuando se citan.
CSS, HTML y nombres de archivos
Las clases CSS suelen emplear minúsculas y guiones por legibilidad, como profile-card, aunque una metodología puede añadir bloques, elementos o modificadores. Los nombres de elementos y atributos HTML definidos por el estándar se escriben con su forma técnica; una clase creada por el equipo sigue la convención del proyecto.
Un nombre de archivo no es lo mismo que una clase o una variable. La sensibilidad a mayúsculas depende del sistema de archivos, y una ruta puede romperse al cambiar UserProfile.js por userProfile.js. Renombrar símbolos y archivos requiere herramientas de refactorización y pruebas, no una conversión masiva de texto.
Acentos, eñes, Unicode y transliteración
Muchos lenguajes modernos permiten identificadores Unicode, pero la posibilidad técnica no determina la política del proyecto. Algunas guías restringen los identificadores públicos a ASCII para facilitar interoperabilidad, búsquedas, teclados y herramientas. No elimines tildes o la ñ de datos de personas para fabricar identificadores: generá un nombre técnico separado y conservá el valor original.
La normalización Unicode tampoco equivale a cambiar la caja. Dos cadenas visualmente iguales pueden tener representaciones distintas, y normalizarlas exige una decisión técnica específica. Un conversor de camelCase no sustituye una política de codificación, validación o migración.
Cómo elegir una convención sin inventar reglas
- Identificá el lenguaje, framework y tipo de símbolo.
- Consultá la guía oficial y la configuración del proyecto.
- Revisá nombres equivalentes en el mismo módulo.
- Separá símbolos nuevos de APIs, datos y rutas ya publicados.
- Definí cómo tratar siglas, números y palabras compuestas.
- Generá una propuesta y comprobá colisiones.
- Usá refactorización para renombrar código existente.
- Ejecutá pruebas, linters y compilación antes de integrar el cambio.
Aplicación práctica: la herramienta de formatos para código puede convertir una lista a camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE o dot.case. Usala para preparar nombres nuevos; no la apliques a un repositorio sin revisar referencias y contratos.
Convertir formatos para códigoEjemplos comparados
| Contexto | Opción coherente | Problema a evitar |
|---|---|---|
| Función Python | calculate_invoice_total | Mezclarla con calculateInvoiceTotal sin una razón del proyecto. |
| Clase Java | InvoiceCalculator | Usar una forma de variable para un tipo público. |
| Parámetro .NET | invoiceId | Distinguir dos parámetros solo por mayúsculas. |
| Constante de configuración | MAX_UPLOAD_SIZE | Suponer que la caja garantiza inmutabilidad. |
| Clave JSON externa | invoice_id | Cambiarla en un ejemplo si el contrato real no cambia. |
| Clase CSS | invoice-summary | Aplicar PascalCase solo porque se usa en clases de programación. |
Errores frecuentes
- Tratar camelCase como una regla universal.
- Renombrar una API pública solo para uniformar el aspecto.
- Escribir toda variable global en mayúsculas aunque no sea constante.
- Alterar siglas sin comprobar la convención del proyecto.
- Transformar claves JSON, rutas o variables de entorno dentro de ejemplos.
- Crear identificadores que solo se distinguen por la caja.
- Eliminar tildes de datos originales en lugar de generar un identificador separado.
- Usar un conversor masivo en vez de una herramienta de refactorización.
Lista de comprobación
- ¿La convención pertenece al lenguaje o al proyecto?
- ¿El símbolo es nuevo o ya forma parte de una interfaz?
- ¿Su categoría —variable, función, clase, constante— está clara?
- ¿Las siglas y los números siguen el patrón acordado?
- ¿El nombre evita colisiones por diferencias de caja?
- ¿Los datos externos y las rutas se conservan exactamente?
- ¿El cambio se aplica mediante refactorización?
- ¿Las pruebas y el linter confirman el resultado?
Fuentes consultadas
Preguntas frecuentes
¿Las variables deben escribirse siempre en camelCase?
No. camelCase es frecuente en JavaScript y en otros entornos, pero Python suele preferir snake_case y cada lenguaje o proyecto puede fijar otra convención. La guía local del código tiene prioridad.
¿Las clases se escriben siempre en PascalCase?
PascalCase es habitual para clases y tipos en varios lenguajes, pero no es una regla universal. Comprobá la documentación oficial y el estilo ya utilizado por el proyecto.
¿Una constante tiene que escribirse en MAYÚSCULAS?
No en todos los lenguajes. Python y muchas bases JavaScript usan CONSTANT_CASE para constantes, mientras que otros entornos aplican PascalCase o distinguen constantes por su declaración, no solo por el nombre.
¿Puedo convertir automáticamente una lista de identificadores?
Sí, como preparación, siempre que revises siglas, números, palabras reservadas, nombres públicos y compatibilidad con el proyecto. Renombrar símbolos existentes también exige actualizar todas sus referencias.