O que são nomes compostos chiques
Esse termo "nomes compostos chiques" apareceu na minha lista de coisas que eu precisava explicar pra cara que estava começando em desenvolvimento backend e achava que ia resolver um problema de legibilidade com naming. Vou direto ao ponto. O conceito basicamente se refere a convenções de nomenclatura compostas que vão além do simples snake_case — você tá falando de PascalCase, camelCase, Pascal-snake, kebab-case, e combinações mais específicas como o padrão do Google para proto3 ou as regras do Clean Code pra constantes compostas. A galera nova tende a improvisar. Cria um prefixo aleatório, inventa um separador novo, trata cada módulo como um mundo à parte. Isso gera uma base de código onde um arquivo tem camelCase, outro snake_case, e o terceiro inventou um hífen com underline misturado. Você passa horas procurando uma classe e não consegue porque ninguém seguiu padrão nenhum.
Preciso de nomes compostos chiques no meu projeto?
Depende. Se você tá fazendo um script Python de automação que vai rodar uma vez e morrer, não precisa. Se é um microserviço que vai passar por seis desenvolvedores num ano, sim. A diferença entre um projeto que você consegue dar manutenção e um que você foge de medo é basicamente isso: convenção de nomes consistente. Eu tive um caso recente que vale a pena citar. Um cliente pediu pra refatorar um sistema Node.js onde os nomes dos arquivos seguiam três convenções diferentes no mesmo repositório. O módulo de pagamento usava PascalCase, o de autenticação usava kebab-case, e o de notificação tinha um monte de variáveis em camelCase com sufixos tipo _helper e _util mixurados. A coisa mais crítica foi a função de build que quebrava em produção porque o webpack via "AuthService.ts" num caminho e "auth-service.ts" noutro, e o TypeScript não gerava erro porque os caminhos relativos resolviam de formas diferentes no Linux versus no CI que roda em Windows. A solução foi rodar um script de normalização com o ESLint rule `consistent-file-naming` e um rename batch via Node, mapeando todos os imports antigos pros novos caminhos antes de aplicar as novas convenções. Isso economizou umas 4 horas de debugging que seria gasto caçando módulos inexistentes.
nomes compostos chiques não é sobre parecer elegante. É sobre preguia de leitura. Você quer que qualquer pessoa que chegar no código saiba, sem pensar, onde encontrar uma classe, qual o tipo de cada arquivo, e como se chama uma constante sem precisar abrir o arquivo pra descobrir.
Como implementar na prática
Comece definindo o padrão antes de escrever código. Tem gente que define a regra no meio do trabalho e aí já tá tudo escrito errado. Eu recomendo decidir isso na primeira semana, antes de commitar a primeira linha. Para JavaScript/TypeScript, a maioria dos times usa PascalCase para classes e interfaces, camelCase para funções e variáveis, e UPPER_SNAKE_CASE pra constantes. Isso é tão batido que quase todo linter já vem com regras padrões pra isso. O ESLint com `eslint-plugin-import` e `eslint-config-airbnb-typescript` cobre isso automaticamente. Pra Python, o PEP 8 já te dá a resposta: snake_case pra tudo, exceto classes que usam PascalCase e constantes que usam UPPER_SNAKE_CASE. Se alguém insistir em camelCase num projeto Python, provavelmente veio de outra linguagem e não leu o guia da comunidade.
👉 Clique no botão abaixo para saber mais sobre o assunto!
No PHP, o PSR-12 resolve isso de forma quase absoluta. Arquivos usam PascalCase, classes PascalCase, métodos camelCase, constantes UPPER_SNAKE_CASE. Você coloca um `phpcs` com a regra PSR-12 no pipeline e não precisa mais discutir isso em code review. E aqui vai uma coisa que os iniciantes não percebem: o problema não é escolher um padrão, é escolher um padrão e ser consistente. PascalCase sozinho não resolve nada se metade do time usar camelCase e a outra metade não souber a diferença.
O que acontece quando você não padroniza
Você ganha tempo na primeira semana e perde três meses nos três meses seguintes. Isso é uma lei não escrita. Quanto mais gente entra no projeto, mais caro fica manter convenções espalhadas. O custo de onboarding de um dev novo triplica quando ele precisa entender qual convenção vale em qual contexto. Outro problema que muita gente esquece é a parte de integração entre linguagens. Se você tem um backend em Node com uma API REST e um frontend em React, e o backend exporta tipos TypeScript via um esquema OpenAPI, os nomes precisam conversar. Um endpoint que retorna `user_id` no JSON vai conflitar com uma interface TypeScript que espera `userId`. Esse tipo de discrepância gera bugs silenciosos que passam por type checking mas aparecem em runtime. A solução que eu uso hoje é gerar os tipos a partir de um schema único usando uma ferramenta como `openapi-typescript` ou `graphql-codegen`, e proibir nomes manuais. Você define o contrato uma vez, e o resto do código nasce dele.
Edge cases e exceções
Tem situações onde o padrão convencional não se aplica. Constants como `http_status_codes` ou `db_connection_string` às vezes ficam melhores em snake_case mesmo em projetos JavaScript, porque refletem a nomenclatura do sistema externo que você tá consumindo. Forçar camelCase aqui só cria ruído. Da mesma forma, wrappers de bibliotecas de terceiros que já seguem seu próprio padrão de nomes costumam ser melhor mantidos seguindo o original, em vez de reinterpretar. Também tem o caso dos frameworks. O Laravel usa snake_case pra migrations e config, camelCase pra models e services. O Django segue PEP 8 rigorosamente. O NestJS exige PascalCase pra decorators e controllers. Você não vai impor seu padrão num framework que já tem o seu. O correto é aprender o padrão do framework e usar dentro dele, não tentar forçar o seu esquema contra a corrente.
Uma última coisa prática: nomes compostos chiques ficam ruins quando você tenta comprimir informação demais. `getUserActiveOrdersV2ByCategory` é um exemplo clássico de nome que parece inteligente mas é doloroso de ler. Cada segmento adiciona complexidade sem necessariamente adicionar clareza. Eu prefiro nomes curtos com contexto claro em volta, do que nomes longos que tentam resolver tudo sozinhos. O código deve ser fácil de ler, não fácil de adivinhar.
