Entendendo objeto com letra i no dia a dia
O assunto é mais simples do que parece, mas também mais chato do que a maioria dos tutoriais assume. Quando você trabalha com objetos em programação — Python, JavaScript, Java, o que for — usar a letra i como nome de instância é algo que acontece o tempo todo. E acontece porque é prático, não porque seja elegante. Eu vejo desenvolvedores novatos travando sem motivo quando alguém mostra um código com var i = new Objeto() ou i.processar(). A gente cresce achando que i deve ser só para loops. Não é bem assim.
O que é um objeto com letra i e por que existe
Um objeto com letra i é simplesmente uma variável cujo nome começa com i. Nada mais. Pode ser uma instância, um dicionário, um frame, um ítem. O conceito em si não é específico de nenhuma linguagem, mas a forma como cada uma trata isso muda bastante. Em Python, por exemplo, eu uso i como nome de instância pra objetos de interação do usuário há anos. Em JS, o mesmo nome vira variável de loop em 90% dos códigos que eu vejo. A confusão nasce justamente daí: o mesmo caractere, contextos diferentes, legibilidade diferente.
Quando usar e quando não usar
Use i quando o escopo for local, temporário e óbvio. Variável dentro de um método curto, passed as argument, algo que não precisa de identidade própria. O problema é que esse critério é subjetivo e a gente erra com frequência. Não use quando o objeto precisar ser referenciado em múltiplos lugares, passado entre funções, ou quando o código tiver mais de duas camadas de aninhamento. Nesses casos, i vira ruído visual. O cérebro passa a não distinguir se é loop, instância ou por engano.
Um exemplo concreto que eu tive semana passada: eu estava refactorando um módulo de cache onde existia um objeto chamado i que carregava dados de um serviço externo. O código tinha três níveis de async/await. Quando o team review passou, ninguém percebeu que o objeto não era um contador de loop — era uma instância de IndexClient. Perdi duas horas só pra renomear tudo porque o contexto estava poluído. A solução foi trocar i por idx, que ainda é curto, mas deixa claro que não é loop. E ainda mantém a compatibilidade com qualquer regex de busca interna que o time tivesse configurado pra encontrar referências ao índice.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que ninguém te conta sobre variáveis começadas com i
O primeiro ponto: em linguagens como Python, nomes que começam com i_ ou i. são indistinguíveis de qualquer outro prefixo se você não prestar atenção. A convenção de nomes não impõe regra pra isso. É pura prática da equipe. O segundo ponto, mais importante: em muitos linters e formatters, variáveis com um único caractere são automaticamente marcadas como problemáticas. O eslint com a regra one-var-per-line ignorante pode não reclamar, mas o flake8 ou pylint em modo estrito vão. Se você estiver num projeto grande, isso gera ruído real.
Eu já vi times inteiros desistirem de usar i como nome de instância simplesmente porque o CI pipeline começava a falhar em 47 arquivos diferentes. A correção não foi mudar a convenção. Foi ajustar o linter pra ignorar aquele padrão específico.
Alternativas práticas
Se o objeto representa algo do domínio, use um nome que reflita o que ele é. item, index, iface, inst. São todos melhores que i isolado quando o escopo não é claramente um loop. Se você precisa mesmo da brevidade — e há situações onde isso faz sentido, tipo scripts rápidos, notebooks, ou código experimental — mantenha i mas documente no comentário acima da declaração o que ele representa. Isso não é burocracia. É o único jeito de garantir que outra pessoa (ou você daqui a três meses) não gaste tempo decifrando o código.
Resumindo: objeto com letra i funciona quando o contexto é pequeno e controlado. Fora disso, o custo de manutenção supera o ganho de digitação.
