camelCase, snake_case y kebab-case: cuál va en cada lugar

El contexto elige por ti, no tu gusto. camelCase (userName) nombra variables y funciones en JavaScript, Java, Kotlin y Swift. snake_case (user_name) nombra variables y funciones en Python, Ruby y Rust, y columnas en SQL. kebab-case (user-name) va en cualquier lugar que no sea un identificador de programa — URLs, nombres de clase CSS, atributos HTML, nombres de archivo, paquetes de npm — porque en casi todos los lenguajes el guion es el operador de resta y user-name se interpreta como user menos name.

Las excepciones son pocas: la familia Lisp usa guiones para todo, C# escribe sus métodos con mayúscula inicial y Go convierte la primera letra en un modificador de acceso. Ninguna de esas es la que te cuesta tiempo. La que cuesta es el punto de contacto entre un back end en snake_case y un front end en camelCase.

¿Cómo se ve cada convención?

Tres es el número equivocado. Las dos convenciones por las que no preguntaste viven en los mismos archivos que las tres por las que sí.

¿Qué convención espera mi lenguaje?

La mayoría están escritas en algún documento, lo que significa que la discusión ya está resuelta y te la puedes ahorrar.

• Python — PEP 8 es explícito: funciones y variables en snake_case, clases en CapWords, constantes en mayúsculas con guiones bajos.
• JavaScript y TypeScript — camelCase para variables y funciones, PascalCase para clases y componentes. No hay un único documento oficial; la convención viene de la propia biblioteca estándar, llena de toLowerCase y getElementById.
• Java, Kotlin, Swift — camelCase para los miembros, PascalCase para los tipos.
• C# — PascalCase para tipos, métodos y propiedades públicas; camelCase para parámetros y variables locales. Es la excepción más popular de la lista: una llamada a un método ahí parece un nombre de clase en cualquier otro lenguaje.
• Ruby — snake_case para métodos y variables, PascalCase para clases y módulos, mayúsculas para constantes. Lo último lo impone el intérprete: un nombre que empieza con mayúscula es una constante.
• Rust — snake_case para funciones, variables y módulos; UpperCamelCase para tipos y traits; mayúsculas con guiones bajos para constantes y statics. El compilador te avisa cuando te desvías, lo que zanja la mayoría de las revisiones antes de que empiecen.
• Go — MixedCaps, nunca guiones bajos, y la mayúscula tiene consecuencias: un identificador que empieza en mayúscula se exporta desde su paquete, uno que empieza en minúscula no. Aquí las mayúsculas son visibilidad, no estilo. Renombrar count a Count lo publica a todos los paquetes que importan el tuyo.

Cuando un repo ya tiene una convención, síguela aunque sea la que menos te gusta. Un código consistentemente pasado de moda se lee mejor que uno convertido a medias.

Las constantes son el caso casi universal

Las mayúsculas con guiones bajos para constantes valen en toda esa lista salvo en Go, que nombra las constantes en MixedCaps como todo lo demás — MaxRetries, no MAX_RETRIES. Las variables de entorno son lo más parecido a una regla absoluta: las shells, los runtimes de contenedores y todas las herramientas alrededor de los archivos .env dan por hecho mayúsculas con guiones bajos. Un nombre de variable de entorno en minúsculas normalmente funciona y aun así parece un error a quien lo vea después.

Por qué kebab-case no puede ser un nombre de variable

Porque el guion ya es el signo de menos. Escribe user-name = 5 en JavaScript y el parser lee una resta entre una variable llamada user y otra llamada name, y después se niega a asignar al resultado: Invalid left-hand side in assignment. Ponle let delante y falla un paso antes, en el guion mismo. Python responde cannot assign to expression. Java, C#, Go, Rust, PHP y SQL lo rechazan por la misma razón. Esa es toda la historia: kebab-case queda confinado a los lugares donde nada intenta evaluar una expresión.

Hay dos excepciones reales. La familia Lisp — Clojure, Scheme, Emacs Lisp — usa kebab-case para todo, que es por lo que al estilo a veces se le llama lisp-case; el reader de esos lenguajes no trata un guion suelto como un operador. Y las custom properties de CSS se escriben --brand-colour, con guiones incluidos, porque CSS tampoco está evaluando aritmética sobre identificadores.

Dónde kebab-case es la respuesta correcta

• URLs. Google lleva años recomendando guiones en vez de guiones bajos en las URLs, con el argumento de que los guiones se leen como separadores de palabras y los guiones bajos históricamente no. Si les estás poniendo nombre a páginas, qué hace que un slug sea legible y estable importa más que el separador, pero el separador es un guion.
• Clases CSS y atributos HTML. Ambos se escriben por convención en minúsculas con guiones. Lo interesante es el punto de contacto: un atributo data-user-id en el markup se lee desde JavaScript como dataset.userId. El navegador convierte de kebab a camel por ti, que es uno de los pocos lugares donde las dos convenciones están conectadas a propósito.
• Nombres de paquetes npm. npm rechaza de plano las mayúsculas en los nombres de paquetes nuevos, así que la decisión ya está tomada.
• Nombres de archivo. Windows y el sistema de archivos por defecto de macOS no distinguen mayúsculas de minúsculas, así que Readme.md y readme.md son el mismo archivo para el sistema operativo y dos archivos distintos para Git. Minúsculas con guiones esquiva esa discusión para siempre.

¿Qué pasa donde se encuentran dos convenciones?

Dentro de un mismo código, las convenciones son una cuestión de estilo. El costo aparece donde se encuentran dos: un servicio en Python con snake_case, un front end en JavaScript con camelCase y un payload JSON pasando entre los dos. Algo tiene que convertir, y la forma de fallar es que todo el mundo convierta un poco, en lugares distintos, hasta que la mitad de tus objetos llevan created_at y createdAt a la vez y ninguno de los dos se llena de forma confiable.

Elige una capa — el serializador, normalmente — y convierte ahí y en ningún otro lado. La guía de estilo JSON de Google recomienda camelCase para los nombres de propiedad, que es un valor por defecto razonable si no tienes otra restricción, pero la elección importa mucho menos que hacerla una sola vez.

SQL merece su propia advertencia. Los identificadores sin comillas se convierten a una sola caja — el estándar los pasa a mayúsculas, PostgreSQL los pasa a minúsculas — así que una columna que creas como createdAt en realidad se llama createdat. Ponle comillas dobles al crearla y la mayúscula sobrevive, pero entonces todas las consultas que la toquen tienen que ponerle comillas también, para siempre, y olvidarlo una vez es un error, no una errata. snake_case es la convención ahí porque sale de esa conversión sin cambios.

¿Cómo convierto un nombre de una convención a otra?

Renombrar a mano es de donde salen las erratas. Un convertidor de mayúsculas y minúsculas toma un nombre y te devuelve el mismo nombre en camelCase, PascalCase, snake_case, CONSTANT_CASE o kebab-case, que es la forma rápida de mover un identificador de un lenguaje a otro. Corre en el navegador, así que pegar ahí nombres de variables internas no los manda a ningún lado.

Vale la pena conocer dos límites antes de confiar en el resultado. Los acrónimos lo derrotan, y derrotan a todos los conversores de propósito general por la misma razón: la separación depende de una letra minúscula seguida de una mayúscula, y HTTPResponse no tiene ese límite. Te da httpresponse, no http_response; parseXMLFile se convierte en parse_xmlfile. Si tus nombres llevan acrónimos, lee el resultado antes de pegarlo de vuelta.

Las convenciones de programación tratan toda la caja de texto como un solo identificador. Mayúsculas, minúsculas, Title Case y Sentence case funcionan sobre un párrafo, pero camelCase, snake_case y kebab-case colapsan todo lo que pegues — saltos de línea incluidos — en un único nombre. A esos dales un identificador por vez.

¿Cómo renombro una convención en todo un proyecto?

La tentación es un buscar y reemplazar general, y el peligro no es el que la gente espera. La coincidencia de palabra completa evita que userName coincida dentro de userNames. Lo que no evita es que el reemplazo caiga dentro de un string literal, un comentario, una consulta SQL o la clave de un payload de API — así que un renombrado que iba a ser cosmético cambia en silencio el formato de los datos que viajan. Pasar por un reemplazo que lista cada coincidencia con su número de línea antes de comprometerte hace visibles esos casos mientras todavía son baratos.

Ese funciona sobre un bloque de texto que pegas, y lista las primeras cien coincidencias. Sirve para un solo archivo que vas a pegar de vuelta, no para una pasada sobre cien archivos. Para eso quieres sed o la búsqueda en todo el proyecto de tu editor — la misma disciplina: lee las coincidencias antes de reemplazarlas.

Después, lee el diff en vez de la salida de los tests. Comparar el antes y el después lado a lado detecta las tres líneas que no querías tocar más rápido que una suite de tests que solo cubre los caminos en los que pensaste.

¿Importa algo de esto?

Para la corrección no, y para el rendimiento tampoco. Importa para el grep: nombres consistentes significan que una sola búsqueda encuentra todas las apariciones, mientras que los inconsistentes significan que encuentras casi todas y el resto te muerde después. Hay trabajos académicos que comparan qué tan rápido lee la gente snake_case y camelCase, y no zanjan nada: los estudios son pequeños y sus resultados se contradicen entre sí, así que no es una base sólida para decidir. La consistencia es el beneficio que sí puedes observar. Todo lo demás es preferencia disfrazada de principio.

Última actualización 19 de septiembre de 2026