Vra

Ek sien dikwels kode soos:

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

maar ek skryf dit (wanneer Java 1.5 nie beskikbaar is nie of vir elkeen nie gebruik kan word nie) as:

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

want

  • Dit is korter
  • Dit hou i in 'n kleiner omvang
  • Dit verminder die kans op verwarring.(Is i buite die tyd gebruik?Waar is i verklaar?)

Ek dink kode moet so eenvoudig as moontlik wees om te verstaan ​​sodat ek net komplekse kode hoef te maak om komplekse dinge te doen.Wat dink jy?Watter een is beter?

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

Was dit nuttig?

Oplossing

Ek verkies die for-lus, want dit stel ook die omvang van die iterator na net die for-lus.

Ander wenke

Daar is gepaste gebruike vir die while-, die for- en die foreach-konstrukte:

  • while - Gebruik dit as jy herhaal en die beslissende faktor vir lus of nie is bloot gebaseer op 'n toestand.In hierdie luskonstruksie is die hou van 'n indeks slegs 'n sekondêre bekommernis;alles moet gebaseer wees op die toestand

  • for - Gebruik dit as jy lus is en jou primêre bekommernis is die indeks van die skikking/versameling/lys.Dit is nuttiger om 'n vir te gebruik as jy waarskynlik deurgaan almal die elemente in elk geval, en in 'n bepaalde volgorde (bv. gaan agteruit deur 'n gesorteerde lys, byvoorbeeld).

  • foreach - Gebruik dit as jy net deur jou versameling moet gaan, ongeag die bestelling.

Natuurlik is daar uitsonderings op bogenoemde, maar dit is die algemene reël wat ek gebruik wanneer ek besluit om watter te gebruik.Dit gesê ek is geneig om te gebruik foreach meer gereeld.

Hoekom nie die vir-elke konstruk gebruik nie?(Ek het Java lanklaas gebruik, maar dit bestaan ​​in C# en ek is redelik seker dat Java 1.5 dit ook het):

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));

Ek dink omvang is die grootste probleem hier, soos jy uitgewys het.

In die "while"-voorbeeld word die iterator buite die lus verklaar, dus sal dit voortbestaan ​​nadat die lus klaar is.Dit kan probleme veroorsaak as dieselfde iterator op 'n later stadium weer gebruik word.E.g.jy kan vergeet om dit te inisialiseer voordat jy dit in 'n ander lus gebruik.

In die "for"-voorbeeld word die iterator binne die lus verklaar, dus is die omvang daarvan beperk tot die lus.As jy probeer om dit na die lus te gebruik, sal jy 'n samestellerfout kry.

as jy die iterator net een keer gaan gebruik en weggooi, word die tweede vorm verkies;anders moet jy die eerste vorm gebruik

IMHO, die vir lus is minder leesbaar in hierdie scenario, as jy na hierdie kode kyk vanuit die perspektief van Engelse taal.Ek werk aan 'n kode waar skrywer misbruik vir lus, en dit is nie mooi nie.Vergelyk die volgende:

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

vs

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

Ek sal saamstem dat die "vir"-lus duideliker en meer gepas is wanneer dit herhaal word.

Die "terwyl"-lus is geskik vir peiling, of waar die aantal lusse om aan die uitgangvoorwaarde te voldoen sal verander op grond van aktiwiteit binne die lus.

Nie dat dit waarskynlik in hierdie geval saak maak nie, maar samestellers, VM's en SVE's het gewoonlik spesiale optimeringstegnieke wat hulle onder die kap gebruik wat vir lusse se werkverrigting beter sal maak (en in die nabye toekoms parallel), in die algemeen doen hulle dit nie met while-lusse (omdat dit moeiliker is om te bepaal hoe dit eintlik gaan loop).Maar in die meeste gevalle moet kode duidelikheid optimalisering troef.

Deur vir lus te gebruik, kan jy met 'n enkele veranderlike werk, aangesien dit die omvang van veranderlike stel vir slegs 'n huidige werkende lus.Dit is egter nie moontlik in while lus nie.Byvoorbeeld:
int ek;vir(i=0;in1;i++) doen iets..

want(i=0;i n2;i+=2) iets doen.

So na 1ste lus i=n1-1 aan die einde.Maar terwyl jy tweede lus gebruik, kan jy i weer op 0 stel. Egter

int i=0;

while(i less than limit) { doen iets ..;i++;}

Daarom is i ingestel op limiet-1 aan die einde.So jy kan nie dieselfde i in 'n ander while lus gebruik nie.

Albei is goed.Ek gebruik self vir () en ek weet nie of daar saamstelprobleme is nie.Ek vermoed hulle word albei geoptimaliseer tot byna dieselfde ding.

Ek stem saam dat die for-lus gebruik moet word waar moontlik, maar soms is daar meer komplekse logika wat die iterator in die liggaam van die lus beheer.In daardie geval moet jy met terwyl gaan.

Ek was die vir lus vir duidelikheid.Terwyl ek die terwyl lus wanneer hulle met een of ander ondeterministiese toestand gekonfronteer word.

Albei is goed, maar onthou dat toegang tot die Iterator soms direk nuttig is (soos as jy elemente verwyder wat by 'n sekere toestand pas - jy sal 'n ConcurrentModificationException kry as jy collection.remove(o) binne 'n for(T o :versameling) lus).

Ek verkies om die vir (blah :blah) [foreach] sintaksis byna heeltyd omdat dit vir my meer natuurlik leesbaar lyk.Die konsep van iterators in die algemeen het nie regtig parallelle buite programmering nie

Akademie is geneig om die while-lus te verkies, aangesien dit minder ingewikkelde redenasies oor programme maak.Ek is geneig om die for- of foreach-lus-strukture te verkies, aangesien dit makliker leesbare kode maak.

Alhoewel albei baie goed is, is ek geneig om die eerste voorbeeld te gebruik omdat dit makliker is om te lees.

Daar is minder bewerkings wat op elke reël plaasvind met die while()-lus, wat die kode makliker maak vir iemand wat nuut is in die kode om te verstaan ​​wat aangaan.

Daardie tipe konstruk stel my ook in staat om initialisasies op 'n gemeenskaplike plek te groepeer (aan die bokant van die metode) wat ook vir my kommentaar vereenvoudig, en konseptualisering vir iemand wat dit vir die eerste keer lees.

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top