Convenções de nomenclatura para objetos em projetos de desenvolvimento
O assunto não é tão simples quanto parece na primeira vista. Quando você trabalha com múltiplos desenvolvedores, o sistema de nome de objetos em inglês vira o principal ponto de atrito no dia a dia. Eu já vi branches inteiros quebrarem por causa de um objeto nomeado de forma ambígua que outro membro da equipe interpretou diferente.
Como criar um nome de objetos em inglês que funciona na prática
A regra básica é mais restritiva do que a maioria das pessoas gostaria. O nome precisa ser autoexplicativo sem exigir documentação anexa. Quando eu comecei a trabalhar em pipelines de assets para jogos, aprendi isso na dura. Tive um problema específico onde um arquivo chamado "door_glass" foi confundido com "door_glass_v2", e o versionamento do repositório acabou sobreescrevendo a versão correta porque os nomes eram suficientemente similares mas não idênticos. A solução foi adotar um prefixo de contexto obrigatório: "prop_door_glass_v2". Isso eliminou a ambiguidade completamente. O formato que funciona consistentemente é: [categoria]_[subcategoria]_[nome_descritivo]_[variante]. Use sublinhado como separador. Traços criam problemas em sistemas operacionais diferentes e ferramentas de build que não tratam hyphens da mesma forma. Exemplos práticos: "prop_chair_modern_01", "tex_ground_concrete_cracked", "mesh_weapon_pistol_default".
A categoria deve ser um dos termos mapeados num arquivo de convenção do projeto. As categorias comuns são: prop para objetos 3D, tex para texturas, mesh para geometria, mat para materiais, sfx para efeitos sonoros, and ui para elementos de interface. Não reinvente categorias a cada novo projeto. Use as mesmas que o time já domina.
O que todo mundo erra
O erro mais frequente é usar nomes genéricos como "obj_new" ou "final_version_v3". Isso parece inofensivo no início mas gera um custo de manutenção exponencial conforme o projeto cresce. Um projeto com milhares de assets que segue essa prática pode gastar até 40% do tempo de onboarding de um novo desenvolvedor apenas navegando e procurando arquivos pelo menu de busca. Nomes descritivos reduzem esse tempo para menos de 5%. É uma diferença que não aparece em sprints pequenos mas destrói prazos em produções maiores. Outro erro comum é a mistura de idiomas dentro do mesmo namespace. Eu vi equipes tentarem usar nomes em português para assets internos e inglês para exportação. Isso cria duplicação desnecessária e confusão sobre qual versão é a fonte da verdade. Decida um idioma e mantenha. O inglês é a escolha padrão da indústria por uma razão prática: a maioria das ferramentas, engines e plugins foi desenvolvida com esse idioma como base.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Nomenclatura de números e versões
Sempre use padding zero à esquerda em sequências numéricas: _01, _02, _10, nunca _1, _2, _10. Sem isso, a ordenação alfabética natural dos sistemas de arquivos coloca "_10" antes de "_2". Isso quebra importações automáticas em praticamente qualquer pipeline de ferramenta. Ferramentas como Blender, Unity e Unreal contam com ordenação de arquivo para definir hierarquias e referências, e o padding zero resolve isso em minutos sem configuração adicional. Para variantes, use sufixos claros e padronizados. _v1 para versão inicial, _alt para alternativas, _high para resoluções maiores, _low para otimização. Evite siglas internas que só fazem sentido para quem estava na sala quando foi criado. "prop_chair_better" é pior do que "prop_chair_alt" porque é subjetivo e não comunica informação útil.
Limitações do sistema
A abordagem tem pontos fracos que precisam ser gerenciados. Sistemas de naming convention estritos aumentam o tempo de criação inicial em cerca de 30% porque o desenvolvedor precisa pensar antes de salvar. Em protótipos rápidos ou sprints de duas semanas, esse overhead pode não valer a pena. Nesses casos, use uma convenção simplificada com apenas categoria e nome descritivo, sem variantes nem padding, e refatore a nomenclatura antes de integrar ao build final. Além disso, convenções muito rígidas funcionam mal em projetos com assets gerados proceduralmente ou via IA. Ferramentas como Substance Designer ou geradores de textura por IA produzem nomes automáticos que raramente seguem o padrão do projeto. A solução prática é ter um script de pós-processamento que renomeia lotes de assets gerados automaticamente conforme a convenção estabelecida. Esse script leva cerca de 15 minutos para ser configurado e economiza horas de renomeação manual depois.
Recursos para implementação
Existem templates de convenção disponíveis em repositórios abertos que você pode adaptar. O GitHub tem diversos projetos com arquivos de nomenclatura prontos para baixar. Procure por "asset naming convention template" ou "production naming standard". A maioria inclui um arquivo CSV com as categorias padrão e exemplos prontos para copiar. Para equipes que precisam de validação automática, existem plugins para Unity e Unreal que verificam a nomenclatura durante o import de assets e geram warnings quando algo foge do padrão. O plugin de naming validation para Unity, disponível na Asset Store, leva cerca de 10 minutos para configurar e impede que assets com nomes inválidos sejam incluídos no build. Isso elimina a necessidade de revisão manual de nomenclatura em cada atualização.
A tabela abaixo mostra exemplos de objetos comuns e como devem ser nomeados seguindo a convenção descrita: prop_table_kitchen_oak_01 para mesa de cozinha em carvalho.
tex_floor_wood_hardmaple_weathered para textura de piso em madeira.
mesh_light_pendant_brass_v2 para modelo 3D de luminária pendente.
sfx_door_creak_heavy para efeito sonoro de porta rangente.
ui_button_primary_round para elemento de interface.
Manter esse padrão consistente em todo o projeto faz toda a diferença na velocidade de navegação e colaboração. A consistência é mais importante que a perfeição da nomenclatura individual. Um sistema simples seguido por todos funciona melhor do que um sistema complexo seguido por apenas alguns membros da equipe.
