Uma abordagem prática para nomes substantivos em projetos técnicos
Quando você trabalha com modelagem de dados, nomenclatura de APIs ou estruturação de bancos de relatórios, os nomes substantivos aparecem como um dos pontos mais negligenciados e, ao mesmo tempo, mais críticos do projeto. A diferença entre um sistema que escala e um que vira um labirinto de abreviações indecifráveis muitas vezes começa com a decisão de como nomear uma entidade, uma coluna ou um campo. Não se trata apenas de "escolher um nome bonito". É sobre criar uma linguagem interna consistente que qualquer pessoa no time — inclusive você daqui a seis meses — consiga ler sem precisar consultar um glossário.
Conceito central: nomes substantivos
O conceito de nomes substantivos se refere à prática de usar nomes que descrevem o que a coisa é, e não o que ela faz, quando o contexto exige identificação de entidades. Um substantivo captura a natureza do objeto. Um verbo ou sigla captura uma ação ou um atalho que só faz sentido para quem escreveu. Na prática, isso significa que uma tabela se chama cliente e não cli. Um campo se chama data_nascimento e não dn. Um endpoint retorna dados de pedido e não ord. A coerência aparece quando todo mundo no projeto adota essa lógica desde o início.
Como implementar esse padrão no dia a dia
O processo mais viável que eu vejo funcionando começa com um documento vivo, não com uma reunião. Alguma pessoa do time cria um arquivo simples — pode ser um markdown no repositório, uma planilha, ou até um comentário no código — listando as entidades principais do projeto e os nomes padrão para cada uma delas. Esse documento é atualizado sempre que uma nova entidade for criada ou um nome existente for renomeado. Aqui está onde a maioria das pessoas erra: elas tentam impor o padrão depois que o código já existe. Nesse ponto, renomear gera custo de migração, quebras de integração e resistência da equipe. O ideal é aplicar o padrão antes que o projeto cresça além do controle. Se você estiver lidando com código legado, faça um mapeamento primeiro, identifique as entidades mais usadas e priorize a correção delas. Remapear tudo de uma vez raramente funciona.
Eu tive um caso recente em que uma base de dados operacional tinha mais de 200 tabelas com nomes misturados entre português e inglês, alguns pluralizados, outros no singular, outros ainda com abreviações de desenvolvedores que já saíram da empresa. A tabela que mais causava problema era usp_vendas_totais — o prefixo usp_ era de um procedure antigo que ninguém mais sabia o significado. A solução que funcionou foi criar uma view mapeada com o nome correto vendas_totais e desconectar as consultas novas da view antiga, mantendo a compatibilidade com o legado por um período definido.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que você provavelmente vai encontrar
O primeiro erro é a inconsistência entre times diferentes. O time de frontend chama algo de usuarios, o de backend chama de pessoas_fisicas, e o banco de dados tem tb_usuario. Isso gera confusão na hora de fazer JOINs, construir DTOs ou escrever queries manuais. A correção é simples: definir um glossário oficial e exigir que o review de código verifique a aderência. O segundo erro é o uso de id solto sem qualificador. Uma coluna chamada apenas id dentro de uma tabela pedido é aceitável. Mas quando você faz uma query com JOIN entre pedido e usuario, ter id em ambas as tabelas vira um pesadelo. Use pedido_id e usuario_id desde o início, ou defina uma convenção clara de sufixo/prefixo no time.
O terceiro erro, que eu diria que é o mais difícil de corrigir, é a tentação de renomear nomes já consolidados no mercado. Se sua API já expõe cliente_id para clientes externos e parceiros dependentes, mudar para conta_id apenas porque soa mais técnico vai quebrar integrações existentes. Nomeação técnica só deve substituir nomeação clara se houver um motivo real de negócio, não estética.
Quando nomes substantivos não funcionam
Existem cenários em que a rigidez dos nomes substantivos se torna um problema. Em sistemas de alta performance onde cada caractere conta — como kernels, motores gráficos ou processadores de stream em tempo real — nomes curtos e abreviados podem ser necessários por limitações de memória ou latência. Nesses casos, a abreviação é uma escolha consciente, não um atalho preguiçoso. Outro caso é quando o domínio do projeto usa siglas que são padrão na indústria e qualquer variação causaria mais confusão do que clareza. Abreviações como URL, API, HTTP ou ID são amplamente reconhecidas e não precisam ser "traduzidas" para versões por extenso. Forçar identificador_universale em vez de uuid em um projeto técnico só aumenta a carga cognitiva sem benefício real.
Dica prática de implementação
Se você quer aplicar esse padrão hoje, comece com uma validação automática. Configure regras de linting no seu projeto para detectar nomes que não sigam o padrão definido — colunas com prefixos numéricos, nomes em maiúsculas, abreviações não padronizadas. Isso elimina a dependência da memória dos desenvolvedores e transforma a convenção em algo executável, não apenas documental. Uma ferramenta simples como um script de CI que rejeita PRs com naming inconsistente costuma ser suficiente. O tempo médio de implementação dessas regras varia de 2 a 4 horas para um time pequeno, e o ganho em legibilidade ao longo dos meses compensa amplamente o esforço inicial. Projetos que ignoram naming early tendem a gastar entre 15 a 30 horas por releitura de código a cada trimestre para entender o que cada campo representa.
Na prática, o custo de manter nomes mal escolhidos nunca desaparece. Ele só aumenta com o tempo. Escolher nomes substantivos de forma consistente desde o início é uma das decisões mais silenciosas, mas com maior impacto na qualidade do produto final.
