[Java] Array-Inhalt auf Duplikate überprüfen.

[Cobinja]

Tschuldigung, falsch gelesen.

Genau diese Imkrementierung (in der Schleifen-Deklaration) würde ich dann mit reinnehmen. Ist einfach saubereres Anwenden der for-Schleife.

 

[Keita]

Eigentlich war es völlig stumpfsinnig, weil der Zähler i gar nicht (mehr) gebraucht wird, ich hatte ursprünglich i dazu genommen, um die Länge der ArrayList zu bestimmen, d.h. entweder

while (list.size() < 6) {
    Integer obj = new Integer(rand.nextInt(49));
    if (list.contains(obj))
        continue;
    list.add(obj);
}

oder

for (int i =  0; i < 6;) {
    Integer obj = new Integer(rand.nextInt(49));
    if (list.contains(obj))
        continue;
    list.add(obj);
    ++i;
}

wären der richtige Weg.

@tewes
continue, break und ähnliche Kostrunkte würde ich nicht gerade mit goto gleichsetzen…

@Cobinja
IMHO ist es nicht sonderlich sinnvoll stumpf zu inkrementieren, um bei Bedarf wieder zu dekrementieren, daß alle drei Teile der Schleifendeklaration optional sind, hat ja gute Gründe.

greetings, Keita (heute völlig verpeilt)

 

[Cobinja]

Ich hab ja auch nicht gesagt, daß ich diesen Weg als den sinnvollsten ansehe, wenn man aber mit einer for-Schleife mit komplettem Header und einem continue arbeitet, bleibt einem manchmal nichts anderes übrig.

Wenn du dir mal meinen Code in Post #12 anguckst, siehst du zwar eine for-Schleife, aber kein continue, sondern eine geschachtelte do-while-Schleife. Damit kann man sich den (imho stilistisch eher unschönen) Weg mit continue sparen.

 

[krizzelfix]

@Keita: ich habe im Programmierunterricht gelernt das die Sprunganweisungen wie goto continue und break alle schlecht für die übersicht sind.

 

[dcdead]

Also ich bin auch ein Jump-Anweisungen-Befürworter. Und wenn's um die Übersicht geht, ist Keitas Code sicherlich am besten, ganz im Gegensatz zu verschachtelten Schleifen, denn die erhöhen dir oftmals die Komplexität direkt um einen ganzen Exponenten (In diesem Beispiel natürlich nicht ) und der Code ist IMHO erst recht unübersichtlich.

 

[Grenzwert]

Also ich bin auch ein Jump-Anweisungen-Befürworter. Und wenn's um die Übersicht geht, ist Keitas Code sicherlich am besten, ganz im Gegensatz zu verschachtelten Schleifen, denn die erhöhen dir oftmals die Komplexität direkt um einen ganzen Exponenten (In diesem Beispiel natürlich nicht ) und der Code ist IMHO erst recht unübersichtlich.

Alles was du mit der Jump Anweisung realisierst, kannst Du auch mit einer einfachen while Schleife machen. Das macht der Compiler eh nachher selbst.
GOTO, continue, break und solche Sachen zeugen einfach nur von einen schwachen Programmierstiel.

 

[dcdead]

Nen guten Programmierstiel kann man sich ja leisten, hauptsache der Stil passt zu den in deiner Firma verwendeten Konventionen, damit die anderen es verstehen Und außerdem macht es der Compiler andersrum Er macht aus deiner Schleife einen Code mit Sprunganweisung.

 

[Grenzwert]

Nen guten Programmierstiel kann man sich ja leisten, hauptsache der Stil passt zu den in deiner Firma verwendeten Konventionen, damit die anderen es verstehen Und außerdem macht es der Compiler andersrum Er macht aus deiner Schleife einen Code mit Sprunganweisung.

Da hat mir mein Professor mal was anderes erzählt.
Woher hast Du die Info?

 

[Keita]

Mit bedingten und/oder unbedingten Sprunganweisungen kannst du zwar Schleifen bauen, aber umgekehrt dürfte es schwieriger werden...

greetings, Keita

 

[Grenzwert]

Wohlgemerkt: Ich spreche davon was der java Compiler macht. Nicht die tieferen Ebenen.
In java gibt es in dem Sinne ja keine Sprunganweisungen, bis auf die Schleifenabbrüche. Und die lassen sich in jedem Fall vermeiden.

 

[Cobinja]

Bei einfachen Sachen wie in diesem Thread können goto und continue mal eingesetzt werden. Bei komplexeren Aufgaben sollte man einfach aus Gründen der Lesbarkeit auf sie verzichten.

Man stelle sich einfach mal 10000 Zeilen Code vor, in denen dauernd mit Labels und goto gearbeitet wird.

Oder einen Algorithmus, bei dem 5 Schleifen ineinander geschachtelt werden müssen, weil er sonst nicht funktionieren kann. Wenn ich da mit continue arbeiten würde, könnte kein anderer Entwickler später mit diesem Code etwas anfangen, und sei noch so gut kommentiert.

Bei break sieht es anders aus. Es gibt Situationen, da ist ein break wesentlich lesbarer und manchmal sogar zwingend notwendig (switch-case). Nichtsdestotrotz arbeite ich lieber mit "vernünftigen" Schleifen und gehe damit sicher, daß andere meinen Code lesen können, als daß ich es mir einfach und anderen schwer mache und eventuell "schlechten" Code produziere.