Convenciones de nombres: camelCase vs snake_case vs kebab-case vs PascalCase

La famosa broma de Phil Karlton dice que sólo hay dos cosas difíciles en informática: la invalidación de la caché y nombrar cosas. Ya es bastante difícil elegir buenas palabras; luego también debes decidir cómo unirlas. userId, user_id, UserId, user-id y USER_ID describen todos el mismo concepto, y cada uno es correcto en algún lugar. Esta guía explica las principales convenciones, dónde se espera cada una y cómo manejar los casos incómodos acrónimos, números y límites entre sistemas.

Las principales convenciones

Nombre	Ejemplo	Uso típico
el caso del camello	getUserById	Variables y funciones de JavaScript/TypeScript, métodos Java, campos JSON
El caso Pascal	UserProfile	Clases, tipos, componentes de React, métodos de C#
el caso de serpente	get_user_by_id	Python, Ruby, funciones Rust, columnas de SQL
¿Qué es esto?	MAX_RETRIES	Constantes, variables del entorno
En el caso del kebab	user-profile	URL, clases CSS, atributos HTML, nombres de archivos, banderas de la interfaz de usuario
Cuadro del tren	Content-Type	Cabeceras HTTP
punto.caso	app.server.port	Claves de configuración, paquetes Java

Un [convertidor de casos] ((/herramientas/convertidor de casos) puede traducir cualquier nombre entre todos estos a la vez, lo cual es útil cuando se mueven datos entre capas.

Convenciones por idioma y contexto

JavaScript y TypeScript

• Variables, funciones y propiedades de objetos: camelCase.
• Clases, interfaces, alias de tipo, enumeración y componentes de React: PascalCase. React requiere que los componentes comiencen con una letra mayúscula para que JSX pueda distinguirlos de los elementos HTML.
• Constantes verdaderas (configuración que nunca cambia): SCREAMING_SNAKE_CASE, aunque muchas bases de código usan camelCase para variables const.
• Nombres de archivos: a menudo kebab-case (user-profile.tsx) o PascalCase para los archivos componentes. Elige uno; las mayúsculas mezcladas en los nombres de archivos causan problemas en los sistemas de archivos insensibles a mayúsculas y minúsculas.

El Python

PEP 8 es explícito: snake_case para funciones, variables y módulos, PascalCase (que PEP 8 llama CapWords) para clases y SCREAMING_SNAKE_CASE para constantes a nivel de módulo. Un subrayado principal señala "interno": _cache.

¡Vete ahora!

Go utiliza camelCase y PascalCase, y el caso tiene significado: los identificadores que comienzan con una letra mayúscula se exportan desde el paquete, las minúsculas son privadas. El estilo Go mantiene las siglas en mayúscula: userID, HTTPServer, parseURL.

Java y C#

Ambos utilizan PascalCase para clases y camelCase para variables locales. Java utiliza camelCase para métodos; C# utiliza PascalCase para métodos y propiedades públicas.

- ¿Qué haces?

snake_case para funciones, variables y módulos; PascalCase para tipos y rasgos; SCREAMING_SNAKE_CASE para constantes y estáticas. El compilador advierte cuando se desvía.

Base de datos SQL

snake_case es la opción segura para tablas y columnas. En PostgreSQL, los identificadores no citados se pliegan en minúsculas, por lo que una columna creada como "userId" debe ser citada para siempre, mientras que user_id funciona en todas partes. Si los nombres de tablas son singulares (user) o plurales (users) es una cuestión de preferencia del equipo; la consistencia importa más que la elección.

CSS y HTML

Las propiedades de CSS son kebab-case (background-color), por lo que los nombres de clases generalmente siguen: .card-header. Metodologías como el BEM añaden estructura: .card__title--active. Los atributos HTML, incluidos los atributos data-*, son insensibles a la mayúscula y mayúscula; JavaScript expone data-user-id como element.dataset.userId.

Direcciones URL

Utilice kebab-case minúscula para las rutas: /blog/compress-image-to-100kb. Google trata los guiones como separadores de palabras pero subraya como unificadores, por lo que los guiones son mejores para SEO. Evite mayúsculas en las URL; muchos servidores tratan las rutas como sensibles a mayúsculas, creando problemas de contenido duplicado.

Variables del medio ambiente

SCREAMING_SNAKE_CASE: DATABASE_URL, STRIPE_SECRET_KEY. Las shells y las plataformas de contenedores esperan esto, y algunas no permiten guiones en los nombres de variables en absoluto.

Acrónimos e iniciales

Aquí es donde los equipos discuten más. ¿Debería ser parseHTTPResponse o parseHttpResponse? ¿userID o userId?

• ** Trate las siglas como palabras** (parseHttpResponse, userId, XmlParser): recomendadas por las pautas .NET de Microsoft para siglas de más de dos letras, por las guías de estilo Java y JavaScript de Google y por muchas bases de código TypeScript. Evita ejecuciones ilegibles como HTTPSURLConnection y convierte limpiamente entre casos parseHttpResponse se convierte en parse_http_response automáticamente.
• Mantenga las siglas mayúsculas (parseHTTPResponse, userID): estándar en Go y común en el código Java y Objective-C más antiguo.

Los convertidores automáticos dividen parseHTTPResponse como parse / HTTP / Response, lo que funciona, pero HTTPSURLConnection es ambiguo. Si se controla el estilo, tratar los acrónimos como palabras es más robusto.

Números en los nombres

Mantenga los dígitos adjuntos a la palabra a la que pertenecen: version2, utf8Decoder, base64_encode, h1-title. Evite comenzar identificadores con dígitos; la mayoría de los lenguajes lo prohíben, y las clases CSS que comienzan con dígitos requieren escape.

Cruce de fronteras: API y bases de datos

Los sistemas reales mezclan convenciones. Un backend de Python con snake_case sirve un frontend de JavaScript que espera camelCase, respaldado por una base de datos SQL con columnas snake_case. Las opciones:

1. Utilice una convención en el cable. Decida si JSON utiliza camelCase (la opción más común para las API públicas, que coinciden con JavaScript) o snake_case (común en los ecosistemas Python y Ruby, y utilizado por las API como Stripe y GitHub). Documentarlo y aplicarlo en todas partes.
2. Convertir en los bordes. Las bibliotecas de serialización pueden convertir automáticamente: generadores de alias de Pydantic, PropertyNamingStrategies de Jackson o asignaciones de columnas ORM. Dentro de cada capa, el código permanece idiomático.
3. No mezcle dentro de una carga útil. { "userId": 1, "created_at": "..." } es lo peor de ambos mundos.

Al generar tipos de TypeScript de JSON cubiertos en nuestra guía de JSON a TypeScript mantenga los nombres de propiedades exactamente como aparecen en el cable, y convierta en una capa de mapeo si es necesario.

Escoger las palabras correctas

El estilo del caso es la parte fácil. Unas pocas reglas para las palabras mismas:

• Sé específico. data, info y item no dicen nada. invoiceLines dice mucho.
• Use verbos para funciones y sustantivos para valores. calculateTotal() devuelve total.
• ** Nombre booleanos como preguntas.** isActive, hasAccess, shouldRetry.
• Incluir unidades. timeoutMs, maxSizeBytes, durationSeconds previenen toda una clase de insectos.
• ** Evite las abreviaturas** a menos que sean universales (id, url, html). usrCnt ahorra cuatro personajes y le cuesta a cada lector un momento.
• ** Coincida con el idioma del dominio.** Si la empresa dice "suscripción", no lo llame plan en código.

Aplicación de los convenios

Escriba las convenciones y deje que las herramientas las apliquen: la regla @typescript-eslint/naming-convention de ESLint, Pylint y Ruff para Python, golint y go vet, los lints incorporados de Rust y stylelint para los patrones de clases CSS. Las comprobaciones automatizadas ponen fin a los debates en la revisión del código y mantienen consistentes las grandes bases de código.

Resumen

Utilice camelCase para valores de JavaScript, PascalCase para tipos y componentes, snake_case para Python, Rust y SQL, kebab-case para URL, CSS y nombres de archivo, y SCREAMING_SNAKE_CASE para constantes y variables de entorno. Trate los acrónimos como palabras cuando pueda, mantenga las unidades en los nombres, elija una convención para cada API, y deje que los linters hagan cumplir las reglas para que los humanos puedan concentrarse en elegir buenas palabras.