Estilos de nomes e convenções explicados
Nomes em código, arquivos, URLs e títulos seguem convenções que mudam de uma linguagem e de um formato para outro. Este guia reúne os estilos mais comuns, onde cada um é esperado e os detalhes que mais confundem: siglas, números, títulos e letras fora do inglês.
Os estilos mais comuns
| Estilo | Exemplo | Como é formado |
|---|---|---|
| camelCase | orderTotal | Primeira palavra em minúsculas, as seguintes com inicial maiúscula, sem separador |
| PascalCase | OrderTotal | Todas as palavras com inicial maiúscula, sem separador |
| snake_case | order_total | Minúsculas, palavras unidas por _ |
| CONSTANT_CASE | ORDER_TOTAL | Maiúsculas, palavras unidas por _ |
| kebab-case | order-total | Minúsculas, palavras unidas por - |
| dot.case | order.total | Minúsculas, palavras unidas por . |
| Title Case | Order Total | Palavras separadas por espaços, cada uma com inicial maiúscula |
| Sentence case | Order total | Só a primeira palavra com inicial maiúscula |
O camelCase às vezes é chamado de lower camel case e o PascalCase de upper camel case. O CONSTANT_CASE também é conhecido como screaming snake case.
Qual estilo cada linguagem e formato espera
A maioria dos ecossistemas definiu uma convenção há muito tempo, e segui-la deixa o código mais fácil de ler para quem conhece aquele ecossistema:
| Onde | Convenção usual |
|---|---|
| JavaScript, TypeScript, Java | camelCase para variáveis e funções, PascalCase para classes, CONSTANT_CASE para constantes fixas |
| Python (PEP 8) | snake_case para funções e variáveis, PascalCase para classes, CONSTANT_CASE para constantes |
| C# | PascalCase para tipos, métodos e membros públicos; camelCase para variáveis locais e parâmetros |
| Go | PascalCase exporta um nome para fora do pacote; camelCase o mantém privado |
| Ruby, Rust | snake_case para métodos e variáveis, PascalCase para tipos |
| CSS e HTML | kebab-case para propriedades, nomes de classe e atributos data- |
| URLs | kebab-case; o Google recomenda hífens em vez de sublinhados entre as palavras |
| Tabelas e colunas SQL | snake_case, porque muitos bancos de dados convertem nomes sem aspas para uma só caixa |
| Variáveis de ambiente | CONSTANT_CASE, como DATABASE_URL |
| Chaves de configuração | dot.case para configurações aninhadas, como server.port |
| APIs JSON | Não há regra única: muitas usam camelCase, outras snake_case; siga a API com que você trabalha |
O kebab-case não pode ser usado em nomes de variáveis na maioria das linguagens de programação, porque o hífen é lido como sinal de menos: order-total significa order menos total.
Siglas e números
As siglas são onde as convenções mais divergem. Uma escola as mantém em maiúsculas (userID, parseHTML); outra as trata como palavras comuns (userId, parseHtml). Os guias de estilo de Java e JavaScript do Google seguem a segunda abordagem, que mantém claros os limites entre palavras quando siglas se encontram: XmlHttpRequest é mais fácil de separar do que XMLHTTPRequest. As diretrizes .NET da Microsoft mantêm em maiúsculas as siglas de duas letras (IOStream) e colocam em maiúscula só a primeira letra das mais longas (HtmlButton). A API de navegador XMLHttpRequest mistura os dois, por isso costuma ser citada como mau exemplo.
Números não têm maiúscula nem minúscula, então um conversor não consegue saber se utf8Decoder significa “utf8 decoder” ou “utf 8 decoder”. Os conversores geralmente juntam o número à palavra anterior. Escolha uma grafia e use-a em todo lugar.
Title Case e Sentence case em títulos
Nos títulos em inglês, os guias de estilo não colocam maiúsculas em todas as palavras do mesmo jeito. Os estilos AP e Chicago deixam em minúscula artigos, conjunções e preposições curtos, exceto no início ou no fim (“The Lord of the Rings”), e divergem na lista exata. Muitos guias de interface e documentação, incluindo os de documentação para desenvolvedores da Microsoft e do Google, usam Sentence case (“Change your password”), mais fácil de aplicar com consistência e menos formal.
O Title Case do conversor da LeedyBox coloca maiúscula em todas as palavras, o que serve para rótulos e nomes do tipo variável, mas não para uma manchete de jornal: passe as palavras curtas para minúscula à mão depois.
Converter entre estilos perde informação
Toda conversão primeiro divide um nome em palavras, usando maiúsculas e separadores como pistas, e depois junta as palavras no novo estilo. O que o estilo de destino não consegue expressar se perde: parseHTML vira parse_html, e a conversão de volta dá parseHtml. A pontuação também é descartada, então “don't” vira duas palavras.
Por isso, trate um estilo como a fonte de verdade. Se um banco de dados usa snake_case e o código usa camelCase, converta na fronteira toda vez, na mesma direção, em vez de guardar os nomes nas duas formas.
Renomear chaves na fronteira de uma API
Quando um front-end em camelCase conversa com um back-end em snake_case, a maioria das bibliotecas de serialização consegue mapear os nomes automaticamente, então os dados nunca são renomeados à mão. Converter um documento JSON uma única vez, por exemplo dados de teste ou uma resposta de exemplo, é outra tarefa, e o modo “Chaves JSON” do conversor faz isso sem mexer nos valores.
Atenção às colisões: user_name e userName viram a mesma chave em qualquer um dos estilos, e uma sobrescreveria a outra. Símbolos iniciais como _id ou $ref costumam ter significado para um banco de dados ou um esquema específico, então verifique se podem ser renomeados.
Maiúsculas e minúsculas além do inglês
As regras de maiúsculas não são iguais em todos os idiomas. O ß alemão vira SS em maiúscula, então a palavra fica mais longa. O turco tem um i com ponto e um ı sem ponto: seus pares em maiúscula são i → İ e ı → I, enquanto a regra padrão da maioria das linguagens de programação transforma i em I. O toUpperCase() do JavaScript usa a regra padrão; toLocaleUpperCase('tr') aplica a turca. Coreano, chinês e japonês não têm maiúsculas e minúsculas, então só mudam os separadores entre as palavras.
A caixa também pode importar em nomes de arquivo. O Windows e, por padrão, o macOS tratam Readme.md e README.md como o mesmo arquivo, enquanto o Linux os trata como dois. Uma renomeação que só muda a caixa pode passar despercebida em um sistema e quebrar links ou imports em outro.
Perguntas frequentes
camelCase ou snake_case: qual é melhor?
Nenhum é melhor em geral. Use a convenção da linguagem, do framework ou da API com que você trabalha; a consistência dentro de uma mesma base de código importa mais do que a escolha em si.
URLs devem usar hífens ou sublinhados?
Hífens. A orientação do Google sobre URLs recomenda hífens entre as palavras, e slugs em kebab-case como /case-converter/ são a prática comum na web.
Por que o Git não percebe que só mudei a caixa de um nome de arquivo?
Em um sistema de arquivos que não diferencia maiúsculas, o Git muitas vezes trata o nome antigo e o novo como o mesmo arquivo. Renomeie com git mv, por exemplo passando por um nome temporário, para que a mudança fique registrada nos sistemas onde a caixa importa.
Como escrevo uma marca como iPhone ou eBay em camelCase?
Os conversores separam nas maiúsculas, então esses nomes saem como palavras separadas. No código, costuma ser mais claro tratar a marca como uma só palavra (iphoneModel) e manter a grafia oficial só no texto exibido para as pessoas.