camelCase, snake_case e kebab-case: qual vai em cada lugar

Quem escolhe é o contexto, não o seu gosto. camelCase (userName) nomeia variáveis e funções em JavaScript, Java, Kotlin e Swift. snake_case (user_name) nomeia variáveis e funções em Python, Ruby e Rust, e colunas em SQL. kebab-case (user-name) fica em qualquer lugar que não seja um identificador de programa — URLs, nomes de classe CSS, atributos HTML, nomes de arquivo, pacotes npm — porque em quase toda linguagem o hífen é o operador de subtração e user-name é lido como user menos name.

As exceções são poucas: a família Lisp usa hífens para tudo, o C# escreve os nomes dos métodos com maiúscula inicial e o Go transforma a primeira letra em um modificador de acesso. Nenhuma delas é o que custa o seu tempo. O que custa é o ponto de contato entre um back end em snake_case e um front end em camelCase.

Como é cada convenção?

Três é o número errado. As duas convenções sobre as quais você não perguntou moram nos mesmos arquivos que as três sobre as quais perguntou.

Qual convenção a minha linguagem espera?

A maioria está escrita em algum documento, o que significa que a discussão já foi resolvida e você pode pular essa parte.

• Python — a PEP 8 é explícita: funções e variáveis em snake_case, classes em CapWords, constantes em maiúsculas com sublinhados.
• JavaScript e TypeScript — camelCase para variáveis e funções, PascalCase para classes e componentes. Não existe um documento oficial único; a convenção vem da própria biblioteca padrão, cheia de toLowerCase e getElementById.
• Java, Kotlin, Swift — camelCase para os membros, PascalCase para os tipos.
• C# — PascalCase para tipos, métodos e propriedades públicas; camelCase para parâmetros e variáveis locais. É a exceção mais popular da lista: uma chamada de método ali parece um nome de classe em qualquer outra linguagem.
• Ruby — snake_case para métodos e variáveis, PascalCase para classes e módulos, maiúsculas para constantes. A última regra é imposta pelo interpretador: um nome que começa com maiúscula é uma constante.
• Rust — snake_case para funções, variáveis e módulos; UpperCamelCase para tipos e traits; maiúsculas com sublinhados para constantes e statics. O compilador avisa quando você foge do padrão, o que encerra a maioria das revisões antes de elas começarem.
• Go — MixedCaps, nunca sublinhados, e a maiúscula carrega peso: um identificador que começa em maiúscula é exportado do seu pacote, um que começa em minúscula não. Aqui a caixa é visibilidade, não estilo. Renomear count para Count publica esse identificador para todo pacote que importa o seu.

Quando um repo já tem uma convenção, siga-a mesmo que você goste menos dela. Um código consistentemente fora de moda se lê melhor do que um convertido pela metade.

As constantes são o caso quase universal

Maiúsculas com sublinhados para constantes vale em toda essa lista, menos no Go, que nomeia constantes em MixedCaps como todo o resto — MaxRetries, não MAX_RETRIES. As variáveis de ambiente são a coisa mais próxima de uma regra absoluta: shells, runtimes de contêiner e todo o ferramental em volta dos arquivos .env presumem maiúsculas com sublinhados. Um nome de variável de ambiente em minúsculas costuma funcionar e mesmo assim parece um erro para quem olhar depois.

Por que kebab-case não pode ser nome de variável

Porque o hífen já é o sinal de menos. Escreva user-name = 5 em JavaScript e o parser lê uma subtração entre uma variável chamada user e outra chamada name, e depois se recusa a atribuir ao resultado: Invalid left-hand side in assignment. Coloque let na frente e ele falha um passo antes, no próprio hífen. O Python responde cannot assign to expression. Java, C#, Go, Rust, PHP e SQL rejeitam pelo mesmo motivo. É essa a história inteira: kebab-case fica restrito aos lugares onde nada está tentando avaliar uma expressão.

Há duas exceções reais. A família Lisp — Clojure, Scheme, Emacs Lisp — usa kebab-case para tudo, e é por isso que o estilo às vezes é chamado de lisp-case; o reader dessas linguagens não trata um hífen solto como operador. E as custom properties do CSS são escritas --brand-colour, com hífens e tudo, porque o CSS também não está avaliando aritmética sobre identificadores.

Onde kebab-case é a resposta certa

• URLs. O Google recomenda hífens em vez de sublinhados nas URLs há anos, com o argumento de que hífens são lidos como separadores de palavras e sublinhados historicamente não eram. Se você está dando nome a páginas, o que torna um slug legível e estável importa mais do que o separador, mas o separador é um hífen.
• Classes CSS e atributos HTML. Os dois são escritos por convenção em minúsculas com hífens. O interessante é o ponto de contato: um atributo data-user-id no markup é lido a partir do JavaScript como dataset.userId. O navegador converte de kebab para camel por você, que é um dos poucos lugares onde as duas convenções foram ligadas de propósito.
• Nomes de pacote npm. O npm rejeita de cara letras maiúsculas em nomes de pacotes novos, então a decisão já está tomada.
• Nomes de arquivo. O Windows e o sistema de arquivos padrão do macOS não diferenciam maiúsculas de minúsculas, então Readme.md e readme.md são o mesmo arquivo para o sistema operacional e dois arquivos diferentes para o Git. Minúsculas com hífens contorna essa discussão para sempre.

O que acontece onde duas convenções se encontram?

Dentro de um mesmo código, convenção é questão de estilo. O custo aparece onde duas delas se encontram: um serviço em Python usando snake_case, um front end em JavaScript usando camelCase e um payload JSON passando entre os dois. Alguma coisa precisa converter, e o jeito como isso falha é que todo mundo converte um pouco, em lugares diferentes, até que metade dos seus objetos carrega created_at e createdAt ao mesmo tempo e nenhum dos dois é preenchido de forma confiável.

Escolha uma camada — o serializador, normalmente — e converta ali e em nenhum outro lugar. O guia de estilo JSON do Google recomenda camelCase para nomes de propriedade, o que é um padrão razoável se você não tem outra restrição, mas a escolha importa muito menos do que fazê-la uma única vez.

O SQL merece o próprio aviso. Identificadores sem aspas são convertidos para uma única caixa — o padrão converte para maiúsculas, o PostgreSQL converte para minúsculas — então uma coluna que você cria como createdAt na verdade se chama createdat. Coloque aspas duplas na criação e a maiúscula sobrevive, mas aí toda consulta que tocar nela também precisa usar aspas, para sempre, e esquecer uma vez é um erro, não um deslize de digitação. snake_case é a convenção ali porque sai dessa conversão sem mudança.

Como converto um nome de uma convenção para outra?

Renomear na mão é de onde vêm os erros de digitação. Um conversor de maiúsculas e minúsculas pega um nome e devolve o mesmo nome em camelCase, PascalCase, snake_case, CONSTANT_CASE ou kebab-case, que é o jeito rápido de levar um identificador de uma linguagem para outra. Ele roda no navegador, então colar ali nomes de variáveis internas não manda nada para lugar nenhum.

Dois limites valem a pena conhecer antes de confiar no resultado. Siglas derrotam o conversor, e derrotam qualquer conversor de uso geral pelo mesmo motivo: a separação depende de uma letra minúscula seguida de uma maiúscula, e HTTPResponse não tem essa fronteira. Você recebe httpresponse, não http_response; parseXMLFile vira parse_xmlfile. Se os seus nomes têm siglas, leia o resultado antes de colar de volta.

As convenções de programação tratam a caixa de texto inteira como um identificador só. Maiúsculas, minúsculas, Title Case e Sentence case funcionam em um parágrafo, mas camelCase, snake_case e kebab-case achatam tudo o que você colar — quebras de linha incluídas — em um único nome. Passe um identificador por vez para esses modos.

Como renomeio uma convenção em um projeto inteiro?

A tentação é um localizar e substituir geral, e o perigo não é o que as pessoas esperam. A correspondência de palavra inteira impede que userName seja encontrado dentro de userNames. O que ela não impede é a substituição cair dentro de um string literal, de um comentário, de uma consulta SQL ou da chave de um payload de API — então uma renomeação que era para ser cosmética muda em silêncio o formato dos dados que trafegam. Passar por uma substituição que lista cada ocorrência com o número da linha antes de se comprometer deixa esses casos visíveis enquanto ainda são baratos.

Essa funciona sobre um bloco de texto que você cola, e lista as primeiras cem ocorrências. Serve para um único arquivo que você vai colar de volta, não para uma varredura em cem arquivos. Para a varredura você quer o sed ou a busca em todo o projeto do seu editor — mesma disciplina: leia as ocorrências antes de substituir.

Depois, leia o diff em vez da saída dos testes. Comparar o antes e o depois lado a lado pega as três linhas que você não queria tocar mais rápido do que uma suíte de testes que só cobre os caminhos nos quais você pensou.

Isso tudo importa?

Para a correção, não, e para o desempenho, também não. Importa para o grep: nomes consistentes significam que uma busca só acha todas as ocorrências, enquanto nomes inconsistentes significam que você acha quase todas e é mordido pelo resto. Existe trabalho acadêmico comparando a velocidade com que as pessoas leem snake_case e camelCase, e ele não resolve nada: os estudos são pequenos e os resultados se contradizem, então não é base sólida para uma decisão. A consistência é o benefício que dá para observar de verdade. Todo o resto é preferência fantasiada de princípio.

Última atualização 19 de setembro de 2026