Pergunta

Muitas vezes vejo um código como:

Iterator i = list.iterator();
while(i.hasNext()) {
    ...
}

mas eu escrever isso (quando Java 1.5 não está disponível ou para cada não pode ser usado) como:

for(Iterator i = list.iterator(); i.hasNext(); ) {
    ...
}

porque

  • É mais curto
  • Ele mantém i em um escopo menor
  • Reduz a chance de confusão. (É i usado fora do enquanto? Onde está i declarada?)

Eu acho que o código deve ser tão simples de entender quanto possível, de modo que eu só tenho de fazer código complexo para fazer coisas complexas. O que você acha? Qual é melhor?

De: http://jamesjava.blogspot.com/2006/04/iterating. html

Foi útil?

Solução

Eu prefiro o loop for porque também define o escopo do iterador apenas para o loop for.

Outras dicas

Há usos apropriados para o tempo, o para, e as construções foreach:

  • while - Use esta opção se está a iteração e o fator decisivo para looping ou não se baseia apenas em uma condição. Nesta construção de loop, mantendo um índice é apenas uma preocupação secundária; tudo deve ser com base na condição

  • for - Use isso se você estiver looping e sua principal preocupação é o índice do / coleção / lista de matriz. É mais útil para usar um para se você é mais provável que passar por todas os elementos de qualquer maneira, e em uma ordem específica (por exemplo, indo para trás através de uma lista ordenada, por exemplo).

  • foreach -. Use isso se você só precisa passar por sua coleção independentemente do fim

Obviamente existem exceções ao acima, mas essa é a regra geral que eu uso quando tomar a decisão de utilização que. Dito I tendem a usar foreach mais vezes.

Por que não usar a construção for-each? (Eu não usei Java em quando, mas isso existe em C # e eu tenho certeza que Java 1.5 tem isso também):

List<String> names = new ArrayList<String>();
names.add("a");
names.add("b");
names.add("c");

for (String name : names)
    System.out.println(name.charAt(0));

Eu acho que escopo é o maior problema aqui, como você apontou.

No "enquanto" exemplo, o iterador é declarada fora do loop, por isso vai continuar a existir após o loop é feito. Isso pode causar problemas se este mesmo iterador é usado novamente em algum momento mais tarde. Por exemplo. você pode esquecer de inicializar-lo antes de usá-lo em outro loop.

No "para" exemplo, o iterador é declarada dentro do loop, por isso, o seu âmbito é limitado ao loop. Se você tentar usá-lo após o loop, você receberá um erro do compilador.

Se você está indo só para usar o iterador uma vez e jogá-lo fora, a segunda forma é o preferido; caso contrário, você deve usar o primeiro formulário

IMHO, o circuito é menos legível neste cenário, se você olhar para este código a partir da perspectiva do idioma Inglês. Eu estou trabalhando em um código em que o autor faz abuso loop, e não é bonito. Compare seguinte:

for (; (currUserObjectIndex < _domainObjectReferences.Length) && (_domainObjectReferences[currUserObjectIndex].VisualIndex == index); ++currUserObjectIndex)
    ++currNumUserObjects;

vs

while (currUserObjectIndex < _domainObjectReferences.Length && _domainObjectReferences[currUserObjectIndex].VisualIndex == index)
{
    ++currNumUserObjects;
    ++currUserObjectIndex;
}

Concordo que o laço "for" é mais clara e mais apropriado quando a iteração.

O "ao" loop é apropriado para sondagem, ou em que o número de voltas a condição encontram saída será alterada com base na actividade no interior do laço.

Não que isso provavelmente importa neste caso, mas Compiladores, VMs e CPU normalmente têm técnicas especiais de otimização eles utilizador sob o capô que vai fazer para o desempenho loops de melhor (e no futuro próximo paralelo), em geral, eles não fazer isso com while (porque a sua mais difícil de determinar como ele realmente vai funcionar). Mas na maioria dos casos código de clareza, devem otimização trunfo.

Usando o loop você pode trabalhar com uma única variável, como ele define o âmbito da variável para um trabalho atual por apenas loop. No entanto, isto não é possível no loop while . Por exemplo:
int i; for (i = 0; in1; i ++) fazer alguma coisa ..

for (i = 0; n2 i; i + = 2) fazer alguma coisa.

Assim, depois de 1º ciclo i = n1-1 no final. Mas ao usar segundo loop você pode definir i novamente para 0. No entanto

int i = 0;

while (i menos de limite) {fazer algo ..; i ++; }

Assim i está definido para limite-1 no final. Então você não pode usar mesmo eu em outro, enquanto loop.

Ou é bom. Eu uso para () eu mesmo, e eu não sei se há problemas de compilação. Eu suspeito que ambos se otimizado para baixo para praticamente a mesma coisa.

Eu concordo que o loop deve ser usado sempre que possível, mas às vezes há uma lógica mais complexa que controla o iterador no corpo do loop. Nesse caso, você tem que ir com tempo.

Eu era o loop for para maior clareza. Enquanto eu usar o while , quando confrontado com alguma condição undeterministic.

Ambos são bons, mas lembre-se que, por vezes, o acesso ao Iterator directamente é útil (como se você está removendo elementos que correspondem a uma determinada condição - você vai ter um ConcurrentModificationException se você fizer collection.remove (o) dentro de um for ( T o: coleção) circular)

.

Eu prefiro escrever o para (blá: blá) [foreach] sintaxe quase todo o tempo, porque parece mais natural legível para mim. O conceito de iteradores em geral realmente não têm paralelos fora da programação

Academia tende a preferir o tempo de ciclo como faz para o raciocínio menos complicado sobre os programas. I tendem a preferir as estruturas para- ou foreach-loop de como eles fazem para o código mais fácil de ler.

Embora ambos sejam realmente bem, eu tendem a usar o primeiro exemplo porque é mais fácil de ler.

Há menos operações que acontecem em cada linha com o loop while (), tornando o código mais fácil para alguém novo para o código para entender o que está acontecendo.

Esse tipo de construção também me permite inicializações do grupo em um local comum (na parte superior do método), que também simplifica a comentar para mim, e conceituação para alguém lê-lo pela primeira vez.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top