Nome De Objeto Com I

Por que todo mundo usa "i" nos nomes de objetos

Você já deve ter visto código como var item = new Item() ou let instancia = new Classe() em qualquer repositório. A convenção de usar o prefixo i (ou a letra i sozinha como identificador de iteração) é uma das mais discutidas em equipes de desenvolvimento. O assunto "nome de objeto com i" volta sempre quando alguém precisa padronizar nomes ou revisar um pull request. Achei melhor explicar direto o que isso significa na prática, porque a definição técnica não ajuda muito quem está no dia a dia.

O que significa nome de objeto com i na prática

Em muitas linguagens, o uso de i como prefixo indica que aquela variável representa uma instância de uma classe. Em vez de var produto = new Produto(), alguns devs preferem var iProduto = new Produto() para deixar claro, já no início do escopo, que se trata de um objeto e não de um valor primitivo. Já o i sozinho é usado como contador em laços, tipo o clássico for (int i = 0; i < lista.Count; i++). O problema é que nem todo mundo segue a mesma regra. Um time usa i como prefixo de instância, outro usa só para índices, e tem ainda quem ache isso uma má prática completa. A confusão começa aí. No meu caso, trabalhei num projeto legado onde a base misturava os dois estilos. Havia variáveis como iCliente, mas também clienteIndex, i e até item. Quando precisei refatorar uma função que recebia múltiplos objetos e fazia um loop dentro de outro loop, acabei tendo que rastrear três níveis de variáveis chamadas i, j e k. A legibilidade ficou ruim e o bug que encontrei levou cerca de 40 minutos pra ser localizado.

A solução que adotei foi simples: passei a usar i apenas para contadores de loop e iNomeDaClasse (com a classe toda em camelCase depois do i) para instâncias. Ficou iLista, iProduto, iUsuario. O código ganhou consistência e a revisão de código passou a ser muito mais rápida.

Quando essa convenção funciona e quando não funciona

A convenção de nome de objeto com i tem sentido principalmente em linguagens fortemente tipadas, onde o contexto de instância vs. tipo pode ser ambíguoso para quem lê rápido. Em C#, por exemplo, ver iPedido já diz que aquilo é uma instância da classe Pedido. O ganho de clareza é real em código legado e em times grandes, onde diferentes devs escrevem métodos que se cruzam. Mas existem limitações sérias. Primeiro: o i isolado vira uma bagunça em loops aninhados. Não adianta muito usar i como contador e item como variável de iteração, porque item é genérico demais e gera ambiguidade. Segundo: em linguagens dinâmicas como JavaScript, o prefixo i não traz informação de tipo útil, então a convenção perde parte do valor. Também vale notar que frameworks modernos e ferramentas de formatação como o ESLint ou o Roslyn Analyzers no ecossistema .NET têm regras específicas sobre nomenclatura. Algumas equipes-configuram o linter para exigir o prefixo i; outras o proíbem. Não existe padrão universal. O que funciona num time pode soar estranho em outro.

Um ponto que pouca gente menciona: o uso excessivo de prefixos cria ruído visual. Uma linha como iProduto.iCategoria.iSubcategoria fica ilegível muito rápido. Nesse caso, prefira nomes descritivos curtos ao invés de empilhar prefixos. Use produto.Categoria.Subcategoria com nomes claros em cada nível.

Vantagens e desvantagens que eu vi no dia a dia

As vantagens são reais mas limitadas. O prefixo i ajuda em revisão de código quando o time não usa type hints robustos ou quando o código é legado sem anotações. Reduz o tempo gasto tentando entender se uma variável é um objeto ou um dado simples. Em media, consigo identificar a intenção do código 30% mais rápido quando a convenção é seguida consistentemente. As desvantagens aparecem quando o código evolui. Nomeações fixas com prefixo tendem a ficar obsoletas. Se no início você chamou a variável de iLista porque ela continha uma lista, e depois ela passou a conter um dicionário, o nome já não faz mais sentido. Também há o problema da internacionalização: i é universal, mas o resto do nome precisa ser consistente com o padrão do time, e times distribuídos frequentemente acabam criando convenções híbridas que ninguém entende direito. Se seu time tem menos de dez pessoas e usa tipagem forte com IDE moderna, eu recomendo ignorar o prefixo i completamente. Nomes como pedido, cliente e produto são suficientes. O ganho de simplicidade compensa a suposta clareza do prefixo.

Em equipes maiores ou código legado, o nome de objeto com i pode ser uma ferramenta válida de padronização. A chave é aplicar de forma consistente desde o início e documentar a convenção no guia de estilo do projeto. Sem documentação, cada um faz do seu jeito e o código vira um misto incoerente.