A verdade sobre nomes de objetos em inglês que ninguém te conta
Na maior parte dos projetos que vejo, o nome do objeto é a primeira coisa que ninguém revisa, e é também a que mais dor de cabeça causa três meses depois. Você chama uma variável de nome de objeto em inglês, acha que está fazendo o certo, e depois passa duas horas tentando descobrir qual arquivo corresponde a qual componente porque o naming foi inconsistentemente misturado entre português e inglês no mesmo repositório. O problema real não é saber inglês. É a falta de padrão. Uma vez perdi quase um dia inteiro de trabalho porque um modelo 3D veio de um parceiro externo com arquivos nomeados como parede_seca_v2FINAL numa pasta que também tinha floor_join_03. O projeto era uma fachada comercial de 40Andréas. Ninguém havia definido uma convenção antes de começar. Quando o cliente pediu para renomear um dos painéis, eu precisei rastrear o objeto nas referências de cena, nos materiais, nos links do SketchUp e nas citações no CAD. Tudo porque o nome do arquivo e o nome do objeto interno eram coisas diferentes. A minha solução foi escrever um pequeno script em Python que extrai todos os nomes de objetos de cena, cruza com os nomes dos arquivos e gera um relatório de inconsistências. Levou 20 minutos de codificação e economizou seis horas de busca manual. Funciona, mas é trabalhoso demais para ser feito manualmente em qualquer projeto que passe de vinte elementos.
Por que nome de objeto em inglês continua sendo o padrão da indústria
A maioria das ferramentas que usamos — Unity, Unreal, Blender, Revit, Figma, até engines de mobile como Cocos — foi construída com suporte nativo a caracteres latinos e ASCII. Quando você nomeia um objeto em português e coloca ele num pipeline que processa strings automaticamente, os acentos viram caracteres estranhos e o nome quebra em tempo de compilação ou renderização. Isso já aconteceu comigo com um arquivo chamado cachorro_quente num build de Android que simplesmente desaparecia do APK sem nenhum erro no log. A causa era a conversão de encoding. O fix foi renomear tudo para hot_dog e ajustar a referência no código. Aprendi a não confiar mais em nomes com acento em nenhum pipeline que passe por compilação. Outra coisa que os tutoriais não explicam é que ter um nome em inglês não significa nada se o nome não for descobrível. "objeto_teste_01" não diz nada. "menu_nav_container" já informa o propósito e a hierarquia. O padrão que funciona na prática é usar snake_case com grupos prefixados por domínio: ui_, env_, char_, vfx_. Se o seu projeto usa prefí xos diferentes, crie um documento interno e cole ele na raiz do repositório. Eu já vi times inteiros falharem porque dois desenvolvedores usaram btn_ e button_ para o mesmo conceito. O bug de duplicate binding que nasceu disso levou três dias para ser isolado.
Regras práticas para nomear objetos em inglês
O básico que serve para 90% dos casos: Use snake_case. Evite camelCase se o pipeline deleita underscores, que é o caso de Unity e da maioria dos editores visuais. Kebab-case funciona para ativos estáticos em CDNs, mas quebra em nomes de variáveis dentro do código-fonte.
Sempre inclua o tipo no início do nome. cube_light_01 é melhor que light_01 se no mesmo sistema existir também uma point_light_01. A ambiguidade mata performance de debugging. Nunca use palavras genéricas isoladas. box, object, thing são armadilhas. Quando o versionamento começa a acumular, box_v2 é pior que crate_prop_v2 porque não informa o que o objeto representa no mundo do jogo ou da cena.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Mantenha o tamanho sob quinze caracteres até o separador de versão. Nomes longos parecem seguros, mas eles quebram displays de inspector, truncam logs e dificultam a digitação em hotkeys. Se o nome precisa de trinta caracteres, provavelmente você está usando uma única entidade para fazer três coisas diferentes. Documente abreviações aceitáveis. Se o time usa eng para engine, hud para interface, npc para entidade, anote isso num arquivo de convenções. Novos integrantes não vão adivinhar. Eu mantenho um NAMING.md na raiz de cada projeto com cerca de sessenta siglas e exemplos. Leva dez minutos para atualizar e evita cinco horas de perguntas no Slack por sprint.
Armadilhas comuns que começam invisíveis
Um erro frequente é nomear objetos com base no estado atual em vez do papel permanente. Quando uma tela está visível, todo mundo chama de panel_login. Quando o estado muda e ela vira panel_register, o nome já não faz mais sentido. Renomeie para o propósito, não para a view temporária. O painel continua sendo um container de auth, independentemente de qual etapa o usuário está passando. Outro erro silencioso é duplicar informação que já está implícita na hierarquia. Se o objeto já está dentro de uma pasta chamada UI/HUD/Menu, chamar o ativo de menu_hud_ui_button é redundância ativa. O nome correto seria apenas btn_confirm. Menos caracteres para digitar, menos chance de erro, mais legibilidade no inspector.
E existe um terceiro problema que poucos mencionam: nomes que parecem seguros mas colidem com keywords da engine. Já vi object, class, public e default serem escolhidos como nomes de asset e causarem erro de compilação em Ce em TypeScript por causa de conflitos de namespace. A correção imediata é consultar o glossário de reserved words da ferramenta antes de confirmar qualquer nome que pareça neutro.
Quando nomear em inglês não resolve
Se o seu público final consome o produto em português, ter nomes de objeto em inglês só ajuda o time de desenvolvimento. Isso é suficiente na maioria dos casos, mas existem cenários em que o padrão entra em conflito direto. Projetos que entregam builds para lojas regionais com internacionalização obrigatória podem precisar de chaves de localização que mapeiem nomes visíveis. Nesse caso, o nome de objeto em inglês permanece no código, mas o arquivo de tradução carrega a versão em português para o usuário final. Separar o nome técnico do nome expositivo evita confusão entre desenvolvedores e localizadores. Se o projeto trabalha com múltiplos mercados simultaneamente, considere usar um identificador numérico ou UUID como backbone e manter o nome em inglês apenas como label legível. Assim, renomeações posteriores não quebram referências cruzadas entre assets, cenas e bancos de dados. Eu uso essa abordagem em pipelines de produção onde o custo de rebuild é alto. Para protótipos e MVPs, o ganho não justifica a complexidade adicional.
Como validar se seus nomes estão funcionando antes do deploy
A forma mais rápida que eu conheço é rodar um lint de naming no repositório antes de cada pull request. Existem configurações prontas para ESLint, flake8 e para o próprio Unity com o RulesOfNaming. Se você não quer instalar nada, um grep simples por padrões inadequados já pega 80 por cento dos problemas. Procure por underscores duplos, letras maiúsculas em snake_case, nomes menores que dois caracteres e palavras reservadas da linguagem-alvo. O tempo de execução varia de dois segundos em repositórios pequenos a cerca de quinze segundos em sistemas grandes, mas esse é um preço baixo para evitar refatoração posterior. Se quiser um link para baixar um config padrão que eu uso nos meus projetos, ele está disponível num gist público com regras para Unity, Unreal e Blender. Não tem configuração automática de install, apenas o arquivo YAML que você copia para a pasta raiz e referencia nas suas ferramentas de CI. Funciona bem e já salvou alguns sprints de ser interrompidos por naming conflicts.
