É uma variável chamada i inaceitável? [fechadas]

Question

Quanto convenções de nomenclatura de variáveis ??ir, deve iterators ser nomeado i ou algo mais semântica como count? Se você não usar i, por que não? Se você sentir que i é aceitável, existem casos de iteração onde ele não deve ser usado?

Answer 1

depende do contexto suponho. Se você onde looping através de um conjunto de objetos em algum coleção, então ele deve ser bastante óbvio a partir do contexto que você está fazendo.

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

No entanto, se não for imediatamente claro a partir do contexto que é que você está fazendo, ou se você estiver fazendo modificações para o índice que você deve usar um nome de variável que é mais indicativo do uso.

for(int currentRow = 0; currentRow < numRows; currentRow++)
{
    for(int currentCol = 0; currentCol < numCols; currentCol++)
    {
        someTable[currentRow][currentCol] = someValue;
    }
} 

Answer 2

"i" através "contador de loop" a um programador. Não há nada de errado com ele.

Answer 3

Aqui está outro exemplo de algo que é perfeitamente aceitável:

foreach (Product p in ProductList)
{
    // Do something with p
}

Answer 4

I tendem a usar i, j, k para loops muito localizadas (só existem para um curto período de tempo em termos do número de linhas de código). Para as variáveis ??que existem mais de uma área de fonte maior, que tendem a usar nomes mais detalhados para que eu possa ver o que eles são para sem buscar de volta no código.

A propósito, acho que a convenção de nomenclatura para estes vieram a linguagem Fortran início de onde eu era a primeira variável inteiro? (A - H foram carros alegóricos)

Answer 5

i é aceitável, com certeza. No entanto, eu aprendi uma tremenda quantidade de um semestre de um professor C ++ eu tinha que se recusou código que não tem um nome descritivo para cada variável única. O simples ato de nomear tudo descritiva me forçou a pensar mais sobre o meu código, e eu escrevi melhores programas depois que claro, não de aprender C ++, mas de aprender a nome de tudo. código completo tem algumas boas palavras sobre este mesmo tema.

Answer 6

i é bom, mas algo assim não é:

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        string s = datarow[i][j].ToString(); // or worse
    }
}

Muito comum para programadores para inadvertidamente trocar o i eo j no código, especialmente se eles têm visão ruim ou seu tema do Windows é "hotdog". Este é sempre um "cheiro de código" para mim -. É meio raro quando isso não se ferrou

Answer 7

i é tão comum que é aceitável, mesmo para pessoas que gostam de nomes de variáveis ??descritivos.

O que é absolutamente inaceitável (e um pecado no meu livro) está usando i, j, k ou em qualquer outro contexto que como um índice inteiro em um loop .... por exemplo.

foreach(Input i in inputs)
{
    Process(i);

}

Answer 8

i é definitivamente aceitável. Não tenho certeza que tipo de justificação eu preciso fazer -. Mas eu usá-lo o tempo todo, e outros programadores muito respeitados fazer tão bem

validação social, eu acho:)

Answer 9

Sim, na verdade, é preferível uma vez que qualquer programador ler o seu código vai entender que ele é simplesmente um iterador.

Answer 10

O que é o valor do uso i em vez de um nome de variável mais específico? Para salvar 1 segundo ou 10 segundos ou talvez, talvez, até mesmo 30 segundos de pensar e de digitação?

O que é o custo de usar i? Talvez nada. Talvez o código é tão simples que usando i está bem. Mas talvez, talvez, usando i vai forçar os desenvolvedores que vêm a este código no futuro ter que pensar por um momento "o que eu quero dizer aqui?" Eles terão que pensar: "é um índice, uma contagem, um deslocamento, uma bandeira?" Eles terão que pensar: "é esta mudança segura, é correto, eu vou estar fora por 1"

Usando i economiza tempo e esforço intelectual ao escrever código, mas pode acabar custando mais esforço intelectual no futuro, ou talvez até mesmo resultar na introdução inadvertida de defeitos devido a mal-entendidos o código.

De um modo geral, a maioria de desenvolvimento de software é a manutenção e extensão, de modo que a quantidade de tempo gasto lendo o seu código vastamente irá exceder a quantidade de tempo gasto escrevê-lo.

É muito fácil de desenvolver o hábito de usar nomes significativos em todos os lugares, e uma vez que você tem esse hábito leva apenas poucos segundos mais para escrever código com nomes significativos, mas então você tem o código que é mais fácil de ler, mais fácil de entender , e mais obviamente correta.

Answer 11

Eu uso i loops curtos.

A razão de OK é que acho que é totalmente implausível que alguém poderia ver uma declaração de iterador tipo, com initializer, e afirmam, em seguida, três linhas mais tarde que não está claro o que a variável representa. Eles estão apenas fingindo, porque eles decidiram que "nomes de variáveis ??significativas" deve significar "nomes longos variáveis".

A razão que eu realmente fazê-lo, é que eu acho que o uso de algo não relacionado com a tarefa específica na mão, e que eu iria usar somente em um pequeno espaço, salva-me preocupante que eu poderia usar um nome que é enganosa, ou ambígua, ou será que algum dia ser útil para algo mais no escopo maior. A razão do "i" em vez de "q" ou "contar" é apenas uma convenção emprestado de matemática.

Não uso i se:

• O corpo do laço não é pequena, ou
• o iterador faz outra coisa senão antecedência (ou recuo) desde o início de uma faixa até o fim do loop:

i não necessariamente tem que ir em incrementos de 1, desde que o incremento é consistente e clara, e, claro, pode parar antes do final do iterand, mas se ele nunca muda de direção, ou não foi modificado por uma iteração do loop (incluindo o uso diabólico de iterator.insertAfter () em um loop para a frente), eu tento lembrar de usar algo diferente. Isso sinaliza "Esta não é apenas uma variável de laço trivial, portanto, este não pode ser um loop trivial".

Answer 12

Se o "algo mais semântica" é "iteração", então não há nenhuma razão para não usar i; é uma linguagem bem compreendida.

Answer 13

eu acho que é completamente aceitável em situações de-loop. Eu sempre achei que isso seja bastante normal e nunca realmente correr em questões de interpretação quando i é usado neste caso. foreach loops ficar um pouco mais complicado e eu acho que realmente depende de sua situação. i raramente ou nunca usar i na foreach, apenas em laços for, como eu acho que eu seja muito un-descritivo nestes casos. para foreach i tente usar uma abreviatura do tipo de objecto a ser enrolado. por exemplo:

foreach(DataRow dr in datatable.Rows)
{
    //do stuff to/with datarow dr here
}

De qualquer forma, apenas o meu $ 0,02.

Answer 14

Ela ajuda se o nome dele algo que descreve o que é um loop através. Mas eu costumo usar apenas i.

Answer 15

Enquanto você estão usando i contar loops, ou parte de um índice que vai de 0 (ou 1 dependendo PL) para n, então eu diria que i é muito bem.

Caso contrário, o seu provavelmente fácil para citar i algo significativo que a sua mais do que apenas um índice.

Answer 16

Gostaria de salientar que i e j são também notação matemática para índices matriciais. E, geralmente, você está percorrer uma matriz. Portanto, faz sentido.

Answer 17

Enquanto você estiver usando-o temporariamente dentro de um loop simples e é óbvio que você está fazendo, com certeza. Dito isto, não existe outra palavra curta que você pode usar em vez disso?

i é amplamente conhecido como um iterador loop, assim que você é realmente mais provável que programadores de manutenção confundir se você usá-lo fora de um loop, mas se você usar algo mais descritivo (como filecounter), torna mais agradável código.

Answer 18

Depende. Se você é iteração sobre um conjunto particular de dados, então eu acho que faz mais sentido usar um nome descritivo. (Eg. filecounter como Dan sugerido).

No entanto, se você estiver executando um loop arbitrário então i é aceitável. Como um companheiro de trabalho descreveu para mim - "esta variável é sempre apenas modificado pela construção de loop i Se isso não é verdade, não use for" i é uma convenção que meios

Answer 19

O uso de i, j, k para contadores de loop INTEIRO remonta aos primeiros dias do Fortran.
Pessoalmente eu não tenho um problema com eles, desde que eles são contagens inteiros.
Mas então eu cresci em Fortran!

Answer 20

meu sentimento é que o conceito de usar uma única letra é bom para loops "simples", no entanto, eu aprendi a usar duplas letras há muito tempo e tem funcionado ótimo.

Eu fiz uma pergunta semelhante na semana passada eo seguinte é parte de minha própria resposta :

// recommended style              ●    // "typical" single-letter style
                                  ●
for (ii=0; ii<10; ++ii) {         ●    for (i=0; i<10; ++i) {
    for (jj=0; jj<10; ++jj) {     ●        for (j=0; j<10; ++j) {
        mm[ii][jj] = ii * jj;     ●             m[i][j] = i * j;
    }                             ●        }
}                                 ●    }

no caso do benefício não é imediatamente óbvio: em busca através de código para qualquer única letra vai encontrar muitas coisas que não são o que você está procurando. a letra i ocorre muitas vezes no código onde não é a variável que você está procurando.

Eu tenho feito desta maneira durante pelo menos 10 anos.

Note que muita gente comentou que quer / ambos os itens acima são "feio" ...

Answer 21

Eu estou indo para ir contra a corrente e não dizer.

Para a multidão que diz "i é entendida como um iterador", que pode ser verdade, mas para mim isso é o equivalente a comentários como 'atribuir o valor 5 a nomes Y. Variável variáveis ??como comentário deve explicar o porquê / o que não como.

Para usar um exemplo de uma resposta anterior:

for(int i = 0; i < 10; i++)
{
    // i is well known here to be the index
    objectCollection[i].SomeProperty = someValue;
}

É muito mais difícil de usar apenas um nome significativo como assim?

for(int objectCollectionIndex = 0; objectCollectionIndex  < 10; objectCollectionIndex ++)
{
    objectCollection[objectCollectionIndex].SomeProperty = someValue;
}

Concedido o (emprestado) nome da variável ObjectCollection está muito mal chamado também.