Convenções de nomeação: camelCase vs snake_case vs kebab-case vs PascalCase

A famosa piada de Phil Karlton diz que há apenas duas coisas difíceis em ciência da computação: invalidação de cache e nomeação de coisas. Escolher boas palavras já é difícil o suficiente; então você também deve decidir como se juntar a elas. userId, user_id, UserId, user-id e USER_ID descrevem todos o mesmo conceito, e cada um está correto em algum lugar. Este guia explica as principais convenções, onde cada uma é esperada e como lidar com os casos difíceis siglas, números e limites entre sistemas.

As principais convenções

Nome	Exemplo	Utilização típica
CameloCaso	getUserById	Variaveis e funções JavaScript/TypeScript, métodos Java, campos JSON
PascalCase	UserProfile	Classes, tipos, componentes do React, métodos C#
caso de serpente	get_user_by_id	Python, Ruby, funções Rust, colunas SQL
- O que é isso?	MAX_RETRIES	Constantes, variáveis ambientais
Caixinha de kebab	user-profile	URLs, classes CSS, atributos HTML, nomes de arquivos, bandeiras CLI
Casca do comboio	Content-Type	Cabeçalhos HTTP
ponto.caso	app.server.port	Chaves de configuração, pacotes Java

Um [case converter] ((/tools/case-converter) pode traduzir qualquer nome entre todos eles de uma só vez, o que é útil ao mover dados entre camadas.

Convenções por língua e contexto

JavaScript e TypeScript

• Variaveis, funções e propriedades de objectos: camelCase.
• Classes, interfaces, alias de tipo, enums e componentes do React: PascalCase. O React requer que os componentes comecem com uma letra maiúscula para que o JSX possa distingui-los dos elementos HTML.
• Constantes verdadeiras (configuração que nunca muda): SCREAMING_SNAKE_CASE, embora muitas bases de código usem camelCase para variáveis const.
• Nomes de ficheiros: frequentemente kebab-case (user-profile.tsx) ou PascalCase para ficheiros componentes. Escolha um; letras maiúsculas misturadas em nomes de arquivos causa problemas em sistemas de arquivos insensiveis a letras maiúsculas.

Python

O PEP 8 é explícito: snake_case para funções, variáveis e módulos, PascalCase (que o PEP 8 chama de CapWords) para classes e SCREAMING_SNAKE_CASE para constantes de nível de módulo. Um sinal de supressão indica "interno": _cache.

Vai .

Go usa camelCase e PascalCase, e caso tem significado: identificadores que começam com uma letra maiúscula são exportados do pacote, minúsculas são privadas. O estilo Go mantém as siglas em maiúsculas: userID, HTTPServer, parseURL.

Java e C#

Ambos usam PascalCase para classes e camelCase para variáveis locais. Java usa camelCase para métodos; C# usa PascalCase para métodos e propriedades públicas.

Resina

snake_case para funções, variáveis e módulos; PascalCase para tipos e características; SCREAMING_SNAKE_CASE para constantes e estáticas. O compilador avisa quando se desvia.

Base de dados SQL

O snake_case é a escolha segura para tabelas e colunas. No PostgreSQL, os identificadores não citados são dobrados em minúsculas, então uma coluna criada como "userId" deve ser citada para sempre, enquanto user_id funciona em todos os lugares. Se os nomes das tabelas são singulares (user) ou plurais (users) é uma questão de preferência da equipe; a consistência importa mais do que a escolha.

CSS e HTML

As propriedades CSS são kebab-case (background-color), então os nomes das classes geralmente seguem: .card-header. Metodologias como a BEM acrescentam estrutura: .card__title--active. Os atributos HTML, incluindo os atributos data-*, são insensiveis a minúsculas e minúsculas e, convencionalmente, kebab-minúsculas; JavaScript expõe data-user-id como element.dataset.userId.

URLs

Use kebab-case minúscula para caminhos: /blog/compress-image-to-100kb. O Google trata os hífenes como separadores de palavras, mas sublinha como juntadores, então os hífenes são melhores para SEO. Evite maiúsculas em URLs; muitos servidores tratam caminhos como sensíveis a minúsculas e minúsculas, criando problemas de conteúdo duplicado.

Variaveis ambientais

SCREAMING_SNAKE_CASE, DATABASE_URL, STRIPE_SECRET_KEY. Conchas e plataformas de contêineres esperam isso, e alguns não permitem traços em nomes de variáveis.

Acrônimos e iniciais

É aqui que as equipas discutem mais. Devia ser parseHTTPResponse ou parseHttpResponse? userID ou userId?

• ** Trate as siglas como palavras** (parseHttpResponse, userId, XmlParser): recomendadas pelas diretrizes .NET da Microsoft para siglas com mais de duas letras, pelos guias de estilo Java e JavaScript do Google e por muitas bases de código TypeScript. Ele evita corridas ilegíveis como HTTPSURLConnection e converte limpamente entre casos parseHttpResponse torna-se parse_http_response automaticamente.
• Mantenha as siglas em maiúsculas (parseHTTPResponse, userID): padrão no Go e comum no código Java e Objective-C mais antigos.

Os conversores automáticos dividem o parseHTTPResponse em parse / HTTP / Response, o que funciona, mas o HTTPSURLConnection é ambíguo. Se você controlar o estilo, tratar acrônimos como palavras é mais robusto.

Números nos nomes

Manter os dígitos ligados à palavra a que pertencem: version2, utf8Decoder, base64_encode, h1-title. Evite iniciar identificadores com dígitos; a maioria das linguagens proíbe isso, e as classes CSS que começam com dígitos exigem escape.

Atravessar fronteiras: APIs e bases de dados

Sistemas reais misturam convenções. Um backend Python com snake_case serve um frontend JavaScript que espera camelCase, apoiado por um banco de dados SQL com colunas snake_case. Opções:

1. ** Use uma convenção no fio.** Decida se o JSON usa camelCase (a escolha mais comum para APIs públicas, correspondendo ao JavaScript) ou snake_case (comum nos ecossistemas Python e Ruby, e usado por APIs como Stripe e GitHub). Documente-o e aplique-o em toda parte.
2. Converter nas bordas. As bibliotecas de serialização podem converter automaticamente: geradores de alias da Pydantic, PropertyNamingStrategies da Jackson ou mapeamentos de colunas ORM. Dentro de cada camada, o código permanece idiomático.
3. Não misture dentro de uma carga útil. { "userId": 1, "created_at": "..." } é o pior dos dois mundos.

Ao gerar tipos de TypeScript a partir de JSON coberto em nosso guia JSON para TypeScript mantenha os nomes de propriedades exatamente como aparecem no fio, e converta em uma camada de mapeamento se necessário.

Escolher boas palavras

O estilo do caso é a parte fácil. Algumas regras para as próprias palavras:

• Seja específico. data, info e item não dizem nada. O invoiceLines diz muito.
• ** Use verbos para funções e substantivos para valores.** calculateTotal() retorna total.
• ** Nomear booleans como perguntas.** isActive, hasAccess, shouldRetry.
• Incluir unidades. timeoutMs, maxSizeBytes, durationSeconds impedir uma classe inteira de bugs.
• Evitar abreviaturas a menos que sejam universais (id, url, html). usrCnt poupa quatro personagens e custa a cada leitor um momento.
• ** Compare o idioma do domínio.** Se a empresa diz "subscrição", não o chame de plan em código.

Aplicação das convenções

Escreva as convenções e deixe as ferramentas aplicá-las: regra @typescript-eslint/naming-convention do ESLint, Pylint e Ruff para Python, golint e go vet, lints incorporados do Rust e stylelints para padrões de classes CSS. As verificações automatizadas encerram os debates na revisão de códigos e mantêm consistentes grandes bases de códigos.

Resumo

Use camelCase para valores JavaScript, PascalCase para tipos e componentes, snake_case para Python, Rust e SQL, kebab-case para URLs, CSS e nomes de arquivos e SCREAMING_SNAKE_CASE para constantes e variáveis de ambiente. Trate as siglas como palavras quando puder, mantenha as unidades em nomes, escolha uma convenção para cada API e deixe que os linters apliquem as regras para que os humanos possam se concentrar em escolher boas palavras.