Por qué la forma de escribir un nombre importa tanto
Pocas decisiones en programación parecen tan pequeñas y tienen tanto impacto acumulado como la forma de escribir los nombres. Un identificador como fecha_ultimo_pago, fechaUltimoPago, FechaUltimoPago o fecha-ultimo-pago describe exactamente lo mismo, pero cada variante transmite información distinta a quien lee el código: el lenguaje en el que se está trabajando, el tipo de elemento que se nombra y, a menudo, si ese valor puede cambiar o no.
La razón de fondo es técnica. La mayoría de los lenguajes no permiten espacios dentro de los identificadores, porque el espacio es un separador entre símbolos. Si se escribe fecha ultimo pago, el compilador o el intérprete ve tres nombres distintos. Para formar un identificador de varias palabras hay que unirlas de alguna manera, y con el tiempo cada comunidad ha consolidado formas preferidas de hacerlo.
Las cuatro convenciones más extendidas son snake case, camel case, Pascal case y kebab case, a las que se suma una variante muy usada para constantes, el screaming snake case. Ninguna es superior en términos absolutos. Lo que sí existe es un estilo esperado en cada lenguaje y en cada contexto, y respetarlo hace que el código resulte familiar para cualquier persona que trabaje con esa tecnología.
En esta guía se explica cómo funciona cada convención, dónde se utiliza, qué dicen las guías de estilo oficiales de los lenguajes más populares, cómo automatizar su cumplimiento con linters y cómo convertir nombres entre estilos cuando distintos sistemas tienen que entenderse, por ejemplo una API en Python y un frontend en TypeScript.
Snake case: guiones bajos y minúsculas
En snake case todas las letras van en minúsculas y las palabras se separan con un guion bajo. El nombre viene de la forma alargada y baja del identificador, que recuerda a una serpiente arrastrándose.
saldo_disponible = 1250.75
numero_de_cuotas = 12
def calcular_interes_mensual(saldo_disponible, tasa_anual):
return saldo_disponible * (tasa_anual / 12)
Es la convención estándar en Python para variables, funciones, métodos y módulos, tal como recoge la guía de estilo PEP 8. También es la norma en Rust para funciones y variables, en Ruby para métodos y variables, y en buena parte de los lenguajes de scripting y del ecosistema de ciencia de datos.
Fuera del código fuente, snake case es muy habitual en bases de datos relacionales. Muchos equipos lo eligen para tablas y columnas porque los motores como PostgreSQL convierten a minúsculas los identificadores que no van entre comillas; un nombre como FechaAlta acaba siendo fechaalta salvo que se escriba siempre entre comillas dobles, lo que resulta incómodo y propenso a errores.
CREATE TABLE prestamos_activos (
id_prestamo BIGSERIAL PRIMARY KEY,
id_cliente BIGINT NOT NULL,
monto_original NUMERIC(12, 2) NOT NULL,
fecha_apertura DATE NOT NULL DEFAULT CURRENT_DATE
);
Su gran ventaja es la legibilidad: el guion bajo actúa como un espacio visual, y los nombres largos se leen casi como texto natural. Su desventaja principal es que ocupa algo más de espacio horizontal que camel case.
Screaming snake case para constantes
La variante en mayúsculas, conocida como screaming snake case o constant case, se reserva en la mayoría de los lenguajes para valores que no deben cambiar durante la ejecución del programa.
TASA_INTERES_MAXIMA = 0.36
DIAS_GRACIA_PAGO = 10
URL_API_PAGOS = "https://api.ejemplo.com/v2/pagos"
const MAX_REINTENTOS = 3;
const TIEMPO_ESPERA_MS = 5000;
En Python no existe una palabra clave que impida reasignar una variable, así que la convención en mayúsculas es una señal para los demás desarrolladores: este valor se considera fijo. Desde Python 3.8 existe además la anotación typing.Final, que permite a los verificadores de tipos detectar reasignaciones:
from typing import Final
LIMITE_CREDITO_INICIAL: Final = 5000
En JavaScript y TypeScript, const impide la reasignación, pero no todas las constantes se escriben en mayúsculas. Es habitual usar screaming snake case solo para valores de configuración o literales conocidos en tiempo de compilación, y mantener camel case para referencias que simplemente no se reasignan, como const usuarioActual = obtenerUsuario().
El mismo estilo aparece en variables de entorno, donde es prácticamente universal:
export DATABASE_URL="postgres://localhost:5432/finanzas"
export STRIPE_SECRET_KEY="sk_test_xxx"
Camel case: la joroba de cada palabra
En camel case la primera palabra va en minúsculas y cada palabra siguiente comienza con mayúscula, sin separadores. Las mayúsculas intermedias forman pequeñas jorobas, de ahí el nombre. A veces se le llama lower camel case para distinguirlo de Pascal case.
const saldoDisponible = 1250.75;
let numeroDeCuotas = 12;
function calcularInteresMensual(saldo, tasaAnual) {
return saldo * (tasaAnual / 12);
}
Es el estilo estándar para variables, funciones y métodos en JavaScript, TypeScript, Java, Kotlin, Swift y Dart. En C# se usa para variables locales y parámetros, aunque los métodos y propiedades públicas van en Pascal case.
Camel case es también el formato más común en las claves de los documentos JSON que consumen aplicaciones web, porque coincide con la forma en que se nombran las propiedades de los objetos en JavaScript:
{
"idCliente": 48213,
"montoSolicitado": 15000,
"plazoMeses": 24,
"fechaSolicitud": "2026-10-31"
}
Es compacto y fácil de escribir, aunque en nombres muy largos puede resultar algo más difícil de leer que snake case, sobre todo cuando se combinan siglas.
Pascal case: todas las palabras en mayúscula inicial
Pascal case es igual que camel case, pero la primera letra de la primera palabra también va en mayúscula. El nombre procede del lenguaje Pascal, que popularizó este estilo. También se le conoce como upper camel case.
interface SolicitudPrestamo {
idCliente: number;
montoSolicitado: number;
plazoMeses: number;
}
class CalculadoraAmortizacion {
constructor(private tasaAnual: number) {}
cuotaMensual(solicitud: SolicitudPrestamo): number {
const tasaMensual = this.tasaAnual / 12;
const factor = Math.pow(1 + tasaMensual, solicitud.plazoMeses);
return (
(solicitud.montoSolicitado * tasaMensual * factor) / (factor - 1)
);
}
}
En casi todos los lenguajes se usa para nombres de clases, interfaces, tipos, enumeraciones y estructuras. Python lo utiliza para clases y excepciones, Java y C# para clases e interfaces, Rust para tipos, traits y variantes de enums, y TypeScript para tipos e interfaces.
En el desarrollo frontend tiene un papel especialmente importante: en React los componentes deben empezar con mayúscula, porque JSX interpreta las etiquetas en minúscula como elementos HTML nativos.
function TarjetaResumenCuenta({ saldo }: { saldo: number }) {
return <section className="tarjeta-resumen">Saldo: {saldo}</section>;
}
export default function PanelCliente() {
return <TarjetaResumenCuenta saldo={1250.75} />;
}
C# va un paso más allá y aplica Pascal case también a métodos, propiedades públicas y espacios de nombres, lo que da a su código un aspecto muy reconocible.
Kebab case: guiones medios para la web
En kebab case todas las letras van en minúsculas y las palabras se separan con guiones medios. El nombre alude a las palabras ensartadas en un pincho.
https://ejemplo.com/blog/como-calcular-el-interes-compuesto
No se puede usar para variables en la mayoría de los lenguajes, porque el guion se interpreta como el operador de resta: saldo-disponible significa restar disponible a saldo. Por eso su terreno natural está fuera del código de aplicación.
Su uso más importante está en las URLs. Los motores de búsqueda interpretan el guion medio como separador de palabras, y una URL en kebab case es fácil de leer y compartir. Los slugs de los gestores de contenido y de generadores estáticos como Hugo siguen este formato.
También es la norma en CSS para nombres de clases, propiedades y variables personalizadas:
:root {
--color-fondo-principal: #0f172a;
--espaciado-tarjeta: 1.5rem;
}
.tarjeta-resumen {
background-color: var(--color-fondo-principal);
padding: var(--espaciado-tarjeta);
}
Otros contextos habituales son los atributos HTML personalizados (data-id-cliente), los nombres de paquetes de npm, los nombres de archivos en muchos proyectos frontend, las opciones largas de la línea de comandos y las claves de algunos archivos de configuración:
npm install date-fns
git log --since="2 weeks ago" --no-merges
services:
api-pagos:
image: ejemplo/api-pagos:latest
restart: unless-stopped
Lisp y Clojure son excepciones notables: en estos lenguajes el guion es un carácter válido en los identificadores y kebab case es el estilo estándar para funciones y variables.
Qué convención usar en cada lenguaje
Las guías de estilo oficiales o ampliamente aceptadas de cada lenguaje definen expectativas claras. Seguirlas evita discusiones y hace que el código encaje con las librerías del ecosistema. Este resumen recoge las más habituales:
Lenguaje Variables/funciones Clases/tipos Constantes Archivos/módulos
Python snake_case PascalCase SCREAMING_SNAKE snake_case
JavaScript camelCase PascalCase SCREAMING_SNAKE kebab-case o camelCase
TypeScript camelCase PascalCase SCREAMING_SNAKE kebab-case o camelCase
Java camelCase PascalCase SCREAMING_SNAKE PascalCase (igual que la clase)
C# camelCase (locales) PascalCase PascalCase PascalCase
Go camelCase PascalCase camelCase minúsculas
Rust snake_case PascalCase SCREAMING_SNAKE snake_case
Ruby snake_case PascalCase SCREAMING_SNAKE snake_case
PHP camelCase PascalCase SCREAMING_SNAKE PascalCase (PSR-4)
Go merece una mención especial, porque en este lenguaje la mayúscula inicial no es solo estilo, sino semántica. Un identificador que empieza con mayúscula se exporta y es visible desde otros paquetes; uno que empieza con minúscula es privado al paquete.
package prestamos
// CuotaMensual se exporta: otros paquetes pueden usarla.
func CuotaMensual(monto float64, tasa float64, meses int) float64 {
return calcularFactor(tasa, meses) * monto
}
// calcularFactor es privada del paquete.
func calcularFactor(tasa float64, meses int) float64 {
return tasa / 12
}
En Rust, el compilador emite advertencias cuando no se siguen las convenciones, por ejemplo si una función usa camel case:
warning: function `calcularCuota` should have a snake case name
--> src/main.rs:3:4
|
3 | fn calcularCuota(monto: f64) -> f64 {
| ^^^^^^^^^^^^^ help: convert the identifier to snake case: `calcular_cuota`
|
= note: `#[warn(non_snake_case)]` on by default
En Python, la versión estable actual pertenece a la rama 3.14, y las reglas de nombres de PEP 8 siguen siendo las mismas que hace años: snake case para funciones y variables, Pascal case para clases y mayúsculas para constantes. Son recomendaciones de estilo, no restricciones del intérprete, por lo que su cumplimiento depende de las herramientas y de la disciplina del equipo.
Contextos fuera del código fuente
Las convenciones no se limitan a variables y clases. Cada capa de una aplicación tiene sus propias costumbres, y conocerlas evita choques entre sistemas.
En las bases de datos domina snake case para tablas y columnas, por la razón ya mencionada de la conversión a minúsculas. Elegir nombres de columnas en snake case desde el principio evita tener que entrecomillar identificadores en cada consulta.
En las URLs se prefiere kebab case para las rutas visibles. En los parámetros de consulta conviven varios estilos; lo importante es mantener uno solo en toda la API:
GET /api/v1/clientes/48213/historial-pagos?fecha_desde=2026-01-01&pagina=2
En las cabeceras HTTP se usa tradicionalmente un formato con cada palabra capitalizada y separada por guiones, a veces llamado Train-Case, como Content-Type o X-Request-Id, aunque HTTP/2 y HTTP/3 transmiten los nombres de las cabeceras en minúsculas.
En las variables de entorno el estándar es screaming snake case. En los nombres de ramas de Git, kebab case con prefijos como feature/ o fix/ es la práctica más extendida:
git switch -c feature/calculo-mora-diaria
En los nombres de archivos, cada ecosistema tiene sus costumbres: snake case en Python, Pascal case en archivos de componentes de React en muchos proyectos, kebab case en Angular y en buena parte del frontend. Un factor práctico a considerar es que algunos sistemas de archivos, como el predeterminado en macOS o en Windows, no distinguen mayúsculas de minúsculas, mientras que Linux sí. Renombrar tarjeta.tsx a Tarjeta.tsx puede funcionar en una máquina local y fallar en el servidor de integración continua.
Siglas, números y casos difíciles
Las siglas generan más dudas que cualquier otro aspecto. ¿Se escribe parseHTTPResponse o parseHttpResponse? ¿XMLParser o XmlParser? Las guías difieren. La de C# de Microsoft recomienda capitalizar solo la primera letra de las siglas de más de dos letras (HttpClient, XmlDocument). Go, en cambio, prefiere mantener las siglas en un mismo caso (ServeHTTP, userID). En JavaScript conviven ambas formas incluso en las APIs nativas del navegador, como XMLHttpRequest.
Cuando no hay una guía que obligue, tratar la sigla como una palabra normal suele dar mejores resultados, porque evita bloques de mayúsculas difíciles de leer cuando se encadenan varias siglas:
// Difícil de leer: ¿dónde termina cada sigla?
const parsedHTMLURLID = obtenerId();
// Más claro: cada sigla se trata como una palabra
const parsedHtmlUrlId = obtenerId();
Los números también requieren atención. En snake case suele escribirse direccion_linea_2 o direccion_linea2, y en camel case direccionLinea2. Lo importante es la coherencia, sobre todo cuando un convertidor automático tiene que pasar de un estilo a otro, ya que linea2 y linea_2 producen resultados distintos.
Otro caso complicado son los prefijos privados. En Python, un guion bajo inicial (_saldo_interno) indica que un atributo es de uso interno, y dos guiones bajos activan el name mangling. En JavaScript moderno los campos privados reales se declaran con #, lo que hace innecesaria la antigua convención del guion bajo:
class Cuenta {
#saldo = 0;
depositar(monto) {
this.#saldo += monto;
}
get saldo() {
return this.#saldo;
}
}
Automatizar las convenciones con linters
Confiar en la memoria del equipo para mantener las convenciones no escala. Las herramientas de análisis estático pueden detectar nombres incorrectos antes de que lleguen a la rama principal, y conviene integrarlas en el editor y en la integración continua.
En Python, Ruff incluye las reglas del plugin pep8-naming bajo el prefijo N. Entre ellas, N801 exige Pascal case en clases, N802 minúsculas en funciones y N806 minúsculas en variables dentro de funciones. Se activan en pyproject.toml:
[tool.ruff.lint]
select = ["E", "F", "N"]
ruff check .
servicios/pagos.py:8:5: N802 Function name `CalcularMora` should be lowercase
servicios/pagos.py:14:5: N806 Variable `MontoTotal` in function should be lowercase
Found 2 errors.
En TypeScript, el plugin de typescript-eslint ofrece la regla @typescript-eslint/naming-convention, que permite definir el formato esperado según el tipo de identificador. Con la configuración plana de ESLint (eslint.config.js), una configuración razonable sería:
import tseslint from "typescript-eslint";
export default tseslint.config(...tseslint.configs.recommended, {
rules: {
"@typescript-eslint/naming-convention": [
"error",
{ selector: "default", format: ["camelCase"] },
{
selector: "variable",
modifiers: ["const", "global"],
format: ["camelCase", "UPPER_CASE"],
},
{ selector: "typeLike", format: ["PascalCase"] },
{ selector: "enumMember", format: ["PascalCase"] },
{ selector: "objectLiteralProperty", format: null },
{ selector: "import", format: ["camelCase", "PascalCase"] },
],
},
});
La entrada objectLiteralProperty con format: null desactiva la regla para las propiedades de objetos literales, algo útil cuando se envían cabeceras HTTP o datos a APIs externas que esperan otro estilo. Si en un proyecto se usa React, conviene permitir también Pascal case en funciones para los componentes.
Biome, la alternativa escrita en Rust que combina formateador y linter, ofrece una regla equivalente llamada useNamingConvention, con opciones similares para cada tipo de identificador.
{
"linter": {
"rules": {
"style": {
"useNamingConvention": "error"
}
}
}
}
En Java y Kotlin, herramientas como Checkstyle, ktlint o detekt cubren las mismas comprobaciones, y en Rust las advertencias del compilador y Clippy hacen el trabajo sin configuración adicional.
Convertir nombres entre sistemas
Una situación muy común en aplicaciones reales es que el backend use snake case y el frontend camel case. Una API en Python con FastAPI devuelve naturalmente monto_solicitado, mientras que el cliente en TypeScript espera montoSolicitado. Hay dos soluciones: elegir un único formato para la API y convertir en un extremo, o convertir automáticamente en la frontera.
Con Pydantic v2 se puede definir un generador de alias que expone los campos en camel case sin renunciar a snake case en el código Python:
from pydantic import BaseModel, ConfigDict
from pydantic.alias_generators import to_camel
class SolicitudPrestamo(BaseModel):
model_config = ConfigDict(alias_generator=to_camel, populate_by_name=True)
id_cliente: int
monto_solicitado: float
plazo_meses: int
solicitud = SolicitudPrestamo(id_cliente=48213, monto_solicitado=15000, plazo_meses=24)
print(solicitud.model_dump(by_alias=True))
{'idCliente': 48213, 'montoSolicitado': 15000.0, 'plazoMeses': 24}
Cuando no hay una librería a mano, una función de conversión sencilla resuelve la mayoría de los casos. Esta versión en TypeScript convierte las claves de un objeto, incluidos los objetos anidados y los arreglos:
const aCamel = (texto: string): string =>
texto.replace(/_([a-z0-9])/g, (_, letra: string) => letra.toUpperCase());
function clavesACamel(valor: unknown): unknown {
if (Array.isArray(valor)) return valor.map(clavesACamel);
if (valor !== null && typeof valor === "object") {
return Object.fromEntries(
Object.entries(valor).map(([clave, v]) => [
aCamel(clave),
clavesACamel(v),
])
);
}
return valor;
}
const respuesta = {
id_cliente: 48213,
historial_pagos: [{ fecha_pago: "2026-10-01" }],
};
console.log(clavesACamel(respuesta));
{ idCliente: 48213, historialPagos: [ { fechaPago: '2026-10-01' } ] }
Y en el sentido contrario, en Python:
import re
def a_snake(nombre: str) -> str:
nombre = re.sub(r"([A-Z]+)([A-Z][a-z])", r"\1_\2", nombre)
nombre = re.sub(r"([a-z0-9])([A-Z])", r"\1_\2", nombre)
return nombre.replace("-", "_").lower()
for ejemplo in ["montoSolicitado", "HTTPResponseCode", "fecha-ultimo-pago", "IdCliente"]:
print(f"{ejemplo} -> {a_snake(ejemplo)}")
montoSolicitado -> monto_solicitado
HTTPResponseCode -> http_response_code
fecha-ultimo-pago -> fecha_ultimo_pago
IdCliente -> id_cliente
La segunda expresión regular separa las siglas de la palabra siguiente, de modo que HTTPResponseCode no se convierte en h_t_t_p_response_code. Este tipo de detalles es la razón por la que, en proyectos grandes, conviene usar librerías probadas en lugar de soluciones caseras.
Un caso real: la misma entidad en todas las capas
Ver una misma entidad atravesando todas las capas de una aplicación ayuda a entender por qué conviven varias convenciones sin que eso sea incoherente. Supóngase una plataforma de préstamos personales con una base de datos PostgreSQL, un backend en Python, un frontend en React con TypeScript y una URL pública para consultar cada solicitud.
Capa Nombre de la entidad / campo
Tabla SQL solicitudes_prestamo.monto_solicitado
Modelo Python class SolicitudPrestamo -> monto_solicitado
Respuesta JSON { "montoSolicitado": 15000 }
Tipo TypeScript interface SolicitudPrestamo -> montoSolicitado
Componente React <DetalleSolicitudPrestamo />
Clase CSS .detalle-solicitud-prestamo
URL pública /solicitudes-prestamo/48213
Variable de entorno LIMITE_MONTO_SOLICITUD
Cada nombre respeta la convención de su contexto y, al mismo tiempo, todos comparten las mismas palabras en el mismo orden. Esa es la clave: el estilo cambia, el vocabulario no. Si en la base de datos el campo se llama monto_solicitado, en el frontend no debería llamarse cantidadPedida. Mantener un vocabulario común entre todas las capas permite buscar una entidad en todo el repositorio y encontrarla en cada una de sus formas con una simple búsqueda que ignore mayúsculas y separadores.
Este enfoque también facilita la incorporación de nuevas personas al equipo. Quien conoce las reglas de transformación puede deducir el nombre de una columna a partir del nombre de una propiedad del frontend, o la ruta de una URL a partir del nombre de una clase, sin tener que consultar documentación adicional.
Errores comunes al nombrar
El error más frecuente es mezclar estilos dentro de un mismo proyecto. Encontrar obtener_cliente, obtenerPedido y ObtenerFactura en el mismo módulo obliga al lector a preguntarse si la diferencia significa algo. Una convención de nombres consistente elimina esa carga cognitiva y facilita las búsquedas en el código.
Otro error habitual es importar el estilo de un lenguaje a otro. Escribir Python en camel case porque se viene de Java, o JavaScript en snake case porque se viene de Python, produce código que choca con todas las librerías del ecosistema. El resultado es una mezcla inevitable, porque las funciones propias seguirán un estilo y las de terceros otro.
También es común renombrar archivos cambiando solo mayúsculas en sistemas que no las distinguen. Git puede no detectar el cambio y el problema aparece después en un servidor Linux. La forma segura de hacerlo es con git mv:
git mv tarjeta.tsx Tarjeta.tsx
git commit -m "Renombra componente a PascalCase"
Usar kebab case en claves de objetos JavaScript es otro tropiezo frecuente: obliga a la notación con corchetes (datos["monto-total"]) y rompe la desestructuración. Si una API externa lo exige, lo recomendable es convertir en la frontera y trabajar internamente en camel case.
Por último, la convención correcta no compensa un nombre poco descriptivo. datos_tmp2 cumple snake case a la perfección y aun así no dice nada. El estilo es la forma; el significado sigue dependiendo de elegir bien las palabras.
Buenas prácticas para equipos
La primera recomendación es documentar las decisiones. Un archivo de guía de estilo en el repositorio, aunque sea breve, evita discusiones repetidas en las revisiones de código. Basta con indicar qué guía oficial se sigue y qué excepciones se aplican.
La segunda es delegar el cumplimiento en las herramientas. Configurar el linter con las reglas de nombres, ejecutarlo en un hook de pre-commit y en la integración continua garantiza que el estilo se mantenga sin depender de la memoria de nadie.
# .pre-commit-config.yaml
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: vX.Y.Z # sustituir por la versión más reciente
hooks:
- id: ruff
El valor de rev debe ser la etiqueta más reciente publicada en el repositorio del hook; el comando pre-commit autoupdate la completa y actualiza automáticamente.
La tercera es fijar los formatos en las fronteras: decidir qué estilo usan las claves de la API, los nombres de columnas y los eventos que se publican en colas de mensajes, y aplicarlo de forma uniforme. Cambiar el formato de una API pública después de lanzarla rompe a todos sus consumidores.
La cuarta es respetar el código existente. Al trabajar en un proyecto heredado con una convención poco ortodoxa, suele ser preferible mantenerla antes que introducir un segundo estilo. Si el cambio merece la pena, debe hacerse de forma planificada y completa, idealmente en un commit dedicado que no mezcle refactorizaciones de nombres con cambios funcionales.
Cómo elegir en un proyecto nuevo
Para un proyecto nuevo, la decisión es más sencilla de lo que parece si se sigue un orden. Primero, adoptar la convención oficial del lenguaje principal sin modificaciones. Segundo, para los artefactos fuera del código, aplicar la práctica dominante de cada contexto: snake case en la base de datos, kebab case en URLs y CSS, screaming snake case en variables de entorno. Tercero, decidir el formato de la API según su público: camel case si la consumen sobre todo clientes JavaScript, snake case si la consumen principalmente servicios en Python o Ruby. Lo esencial es que sea uno solo.
En un monorepo con varios lenguajes, cada paquete debe seguir las convenciones de su propio lenguaje. Un servicio en Go no debería escribirse en snake case solo porque el resto del repositorio esté en Python. La coherencia se mide dentro de cada contexto, no forzando un único estilo sobre tecnologías que tienen el suyo.
Si el equipo adopta herramientas de generación de código, como clientes generados a partir de especificaciones OpenAPI, conviene revisar cómo transforman los nombres. Muchos generadores convierten automáticamente snake case a camel case en el cliente, lo que puede ser justo lo que se necesita o una fuente de confusión si no se documenta.
Conclusiones
Snake case, camel case, Pascal case y kebab case resuelven el mismo problema, unir varias palabras sin espacios, pero cada una se ha asentado en contextos distintos. Snake case domina en Python, Rust y las bases de datos; camel case en JavaScript, TypeScript y Java para variables y funciones; Pascal case en clases, tipos y componentes; kebab case en URLs, CSS y la línea de comandos, y screaming snake case en constantes y variables de entorno.
La regla de oro no es elegir la convención más elegante, sino seguir la que espera el ecosistema y aplicarla siempre de la misma manera. Las guías de estilo oficiales, los linters como Ruff, typescript-eslint o Biome, y los convertidores en las fronteras entre sistemas permiten mantener esa coherencia sin esfuerzo manual.
Un código cuyos nombres siguen las expectativas del lenguaje se lee más rápido, se revisa con menos fricción y se integra mejor con las librerías existentes. Es una de las mejoras de calidad más baratas que se pueden adoptar, y sus beneficios crecen con cada línea que se escribe.