Terminologia em desenvolvimento: o que funciona na prática
A gente passa muito tempo discutindo palavras para usar no desenvolvimento quando, na verdade, o problema é outro: a gente não escolhe os termos certos e depois se arrepende quando o código já está rodando há seis meses. Não existe um glossário oficial que todo mundo siga. Cada time monta o seu. O que tem utilidade real são convenções de nomenclatura que reduzem o tempo de compreensão do código e evitam os erros mais comuns de interpretação.
Palavras para usar no desenvolvimento: o básico que ninguém ensina
No dia a dia, os termos que realmente importam são os que aparecem com frequência nas discussions de code review e nos logs de erro. Comece pelo que é óbvio mas todo mundo erra:. Prefira nomes que descrevam o que a função faz, não o que ela contém. Uma função que valida um email não deve se chamar validateEmail se puder ser chamada isEmailValid. A diferença é sutil mas muda completamente a leitura do código quando você está debugging às 3 da manhã.
Aqui vai um exemplo específico que eu tive semana passada: estávamos migrando um sistema legado onde as variáveis de estado usavam prefixes como _is_, _has_, _can_. O problema era que o TypeScript não distinguia entre types de domínio e types de interface UI porque ambos usavam a mesma convenção. Eu renomeei todos os state variables para usar o sufixo State em vez do prefixo is, e isso resolveu metade dos bugs de tipagem que apareciam nos testes automatizados. Demorou cerca de duas horas o refator, mas economizou semanas de debugging depois.
Convenções que funcionam de verdade
O primeiro passo é definir um padrão para camelCase, snake_case e PascalCase dentro do seu projeto. Você precisa saber antes de começar, não decidir no meio do sprint quando ação tá apertada. camelCase para variáveis e funções. PascalCase para classes e componentes. snake_case apenas quando interoperar com APIs externas que exigem, como webhooks de payment providers ou endpoints de legacy systems que não foram modificados em anos.
Uma coisa que poucos mencionam: constant names devem ser SCREAMING_SNAKE_CASE mesmo em projetos que usam camelCase normalmente. Isso não é só convenção estética. Quando o linter vê CONSTANT_NAME, ele sabe imediatamente que aquele valor nunca muda e pode aplicar otimizações de compile-time em algumas linguagens. Em JavaScript especialmente, isso faz diferença real no tree-shaking.
O problema que ninguém fala sobre naming
O maior inimigo não é escolher o nome errado. É escolher um nome que parece certo mas que se torna incorreto quando o requisito muda. Isso acontece o tempo todo em projetos que crescem rápido. Eu trabalhei num projeto onde todos os controllers eram chamados de Manager. Quando o scopeExpandiu e surgiram casos onde o Manager também fazia agendamento de filas, ficou impossível distinguir no code review quem era responsável por quê. A gente teve que renomear metade dos arquivos e atualizar uns 40 imports. Levou um dia inteiro.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A solução que adotamos foi adotar um padrão de domínio: cada nome de classe deve refletir o bounded context do domínio, não a função técnica. UserRegistrationHandler em vez de UserManager. OrderPaymentProcessor em vez de OrderManager. Parece mais trabalho no início mas evita essa situação completamente.
Pitfalls comuns
Evite abreviações. Usuario em vez de Usuário não é problema, mas usr, empls, e addr criam ambiguidade que só aparece quando você volta no código três meses depois. A única exceção que eu aceito é id, que é universalmente entendida como identifier. Qualquer outra abreviação precisa ser justificada e documentada num glossário do projeto. Não use nomes genéricos como data ou info. Se você tem uma variável chamada data, não tem como saber se é um timestamp, uma data de nascimento ou um campo de banco de dados sem ler o contexto. DataCriacao, infoCliente, timestampAtualizacao — são mais caracteres mas salvam tempo de leitura.
Namespaces e módulos devem seguir a hierarquia do domínio. Não faça isso: src/utils/helpers/general.js. Faça src/modules/orders/services/validation.ts. A estrutura de pastas já conta parte da história do código.
Quando a convenção falha
Existem cenários onde seguir as regras estritas piora a legibilidade. API de terceiro com campos em espanhol, sistemas legados com nomenclatura inconsistente, integrações com ERPs que usam códigos como PROD_001 instead of ProductSku. Nesses casos, mantenha o mapeamento interno no seu código mas não espere que o consumidor da API saiba o que cada campo significa. O workaround que eu uso é criar wrappers com nomes claros. Um adapter que traduz fields from the external API into internal conventions. Isso isolaa complexidade num só lugar e mantém o resto do código limpo. Funciona bem quando o wrapper tem menos de 200 linhas. Acima disso, o próprio wrapper vira um problema novo.
Ferramentas úteis
O ESLint com regras de naming é essencial. Configure para reportar variables em snake_case quando o projeto usa camelCase. Use o tsc com strict mode e ele vai te avisar sobre tipos ambíguos que nomes ruins criam. O SonarQube também ajuda a detectar naming inconsistencies em code reviews automáticos. Para projetos grandes, manter um arquivo de convenções no docs/naming.md paga o investimento em uma tarde de configuração. Escreva as regras, dê exemplos do que é aceito e do que não é, e referencie no onboarding de qualquer novo desenvolvedor.
Isso tudo não é teoria. São coisas que eu vi funcionarem e falharem em projetos reais. O tempo que você gasta pensando no nome certo hoje economiza horas de discussão no code review mês que vem.
