for schleife frühzeitig abbrechen

[Andi_CH]

Es gibt doch die elegante Variante der for-schleife

for (String s : args) { ...

Ich möchte an einem bestimmten Punkt abbrechen und keine weiteren Argumente mehr verarbeiten.

Geht das nur mit break (finde ich unschön)
oder mit der alten, komplizierteren, Variante?

for (int i=0; (i<args.length) && !abbruch; i++) {
   abbruch = verarbeite(args[i]);
}

 

[HimBromBeere]

Verstehe zwar nicht, was daran unschön ist, aber wenn du´s so willst:

i = args.length

. DAS wäre dann Holzfeller-Implementierung, aber es sollte gehen 😀 oder noch brachialer: setze deine varargs auf NULL, dann kannste auch die

for (String param: args)

-Variante nehmen, ist aber NOCH hässlicher, wie ich finde...

 

[timbeau]

Keine Idee aber mich würde interessieren, warum break unschön ist?

 

[Andi_CH]

Die erste Variante der for schleife ist doch wirklich viel eleganter, aber break - igit (ich persönlich mag das nicht so )

 

[eRaaaa]

setze deine varargs auf NULL, dann kannste auch die

for (String param: args)

-Variante nehmen, ist aber NOCH hässlicher, wie ich finde...

Funktioniert das denn überhaupt? :bae:

@Andi_CH: es ginge evtl. auch ein return 🙂

 

[bygones]

ich kann nicht verstehen, ich finde breaks ebenso unschoen wie continues.

daher wie eRaaaa sagt, als methode auslagern und per return arbeiten

 

[HimBromBeere]

Funktioniert das denn überhaupt?

Warum nicht? Ist zwar wie gesagt brachiale Holzfällermethode, aber ich wüsste nicht, warum das nicht gehen soll... (die args sind ja schließlich nicht final).

 

[bygones]

Warum nicht? Ist zwar wie gesagt brachiale Holzfällermethode, aber ich wüsste nicht, warum das nicht gehen soll... (die args sind ja schließlich nicht final).

lass mal das laufen

    public static void main(String[] args) {
        String[] all = new String[]{"1","2", "3", "4"};
        for (String param: all) {
            System.out.println(param);
            if (param.equals("1")) {
                System.out.println("bazinga");
                all = null;
            }
        }
    } 
// 1
// bazinga
// 2
// 3
// 4

 

[Andi_CH]

Keine Idee aber mich würde interessieren, warum break unschön ist?

Eine Funktion sollte genau ein einziges "return" statement haben.
Eine Prozedur sollte KEIN return drin haben

Genau so sollte eine Schleife nur im Schleifenkopf (oder halt Fuss im Falle von do - while) abgebrochen werden

Steht das nirgends in der heiligen Schrift der Java Programmierer? Wenn nicht gehört es sofort rein ;-)

 

[bygones]

Eine Funktion sollte genau ein einziges "return" statement haben.
Eine Prozedur sollte KEIN return drin haben

Genau so sollte eine Schleife nur im Schleifenkopf (oder halt Fuss im Falle von do - while) abgebrochen werden

mhm... nein ?! ok... ist deine eigene Meinung.

 

[eRaaaa]

Dekompiliere mal eine foreach....
Dein Vorschlag würde dann so etwas ergeben wie:

		String args[] = { "...", "...", ...};
		String args1[];
		int j = (args1 = args).length;
		for (int i = 0; i < j; i++) {
			String string = args1[i];
			System.out.println(string);  //oder was auch immer..
			args = (String[]) null;  //macht dann wohl nichts :)
		}

 

[HimBromBeere]

Genau so sollte eine Schleife nur im Schleifenkopf (oder halt Fuss im Falle von do - while) abgebrochen werden

Ziemlicher Quatsch wie ich finde. Was ist, wenn innerhalb der Schleife ein Fehler auftaucht und das weitere Abarbeiten dann sinnlos wäre? Dann läufst du im Extremfall noch ein paar hundert Mal durch die Schleife, die bereits beim ersten Element ihren Sinn verloren hat... ich kenne weitaus sinnvollere Methoden, Programmlaufzeiten zu vergeuden...

EDIT: Genauso sinnlos ist es, wenn nur ein einziges return in einer Funktion steht. Oder meinst du damit, dass am Ende nur sowas stehen sollte wie return result und man in den vorigen Codezeilen result bestimmt. Wenn das so gemeint ist, kann ich teilweise zustimmen, weil man nicht ewig suchen muss, an welcher Stelle eine Methode beendet wird.

 

[Andi_CH]

mhm... nein ?! ok... ist deine eigene Meinung.

Komisch Schleifen und Prozeduren an beliebigen Orten verlassen ist ok, ab JA kein p oder m vor die Variablen - Vielleich erreiche ich ja noch den Stand der Weisheit um das zu begreifen ;-)

Dann setze ich halt i auf Integer.MAX 😀 - halt doch lieber die Variable mAbbruch abbruch auf true ;-)

 

[Schandro]

Eine Funktion sollte genau ein einziges "return" statement haben.
Eine Prozedur sollte KEIN return drin haben
Genau so sollte eine Schleife nur im Schleifenkopf (oder halt Fuss im Falle von do - while) abgebrochen werden

Finde ich persönlich nicht, wenn man diese "Regeln" einhält vergeudet man unnötig Zeit und es hat keinen wirklichen Nutzen. Außerdem sind solche Methoden imho schwerer zu lesen. Natürlich gibt es Methoden die extrem unschön programmiert sind und die auch sowas benutzen, aber das heisst ja nicht das returns und break ansich unschön sind.

Dann setze ich halt i auf Integer.MAX - halt doch lieber die Variable mAbbruch abbruch auf true

Anstatt einfach break; zu schreiben? Ernsthaft? Also mal ganz ehrlich, ein break wäre an der Stelle schöner und selbsterklärender.

 

[maki]

Eine Funktion sollte genau ein einziges "return" statement haben.
Eine Prozedur sollte KEIN return drin haben

Genau so sollte eine Schleife nur im Schleifenkopf (oder halt Fuss im Falle von do - while) abgebrochen werden

Steht das nirgends in der heiligen Schrift der Java Programmierer? Wenn nicht gehört es sofort rein ;-)

Auf die Gefahr hin dass du das persönlich nehmen könntest:
Sorry, hat mit Java nix zu tun.

Sowas wie Prozeduren gibt es nicht in Java.
Zum Rest steht schon etwas in "Clean Code" 😉

Ansonsten würde ich die for Schleife auch eine eigene Methode auslagern und dann reicht ein return anstatt eines break...

 

[SlaterB]

Auf die Gefahr hin dass du das persönlich nehmen könntest:
Sorry, hat mit Java nix zu tun.

Sowas wie Prozeduren gibt es nicht in Java.

das ist unnötig, vielleicht gibt es diese Benennung nicht, aber doch offensichtlich Methoden mit und ohne Rückgabewert,
also könnte man die Regeln 'nur einmal return' + 'kein return' problemlos anwenden, zur Verdeutlichung von Funktionen und Prozeduren sprechen,

man muss diese Regeln nicht gut finden, aber strukturell passen sie doch bestens auch in Java..

 

[ThreadPool]

Warum nicht? Ist zwar wie gesagt brachiale Holzfällermethode, aber ich wüsste nicht, warum das nicht gehen soll... (die args sind ja schließlich nicht final).

Im Fall der for-each-Variante wird das nicht helfen da diese einen Iterator auf die zugrundeliegende Reihung organisiert und es danach egal ist ob du die Referenz ebendieser auf null setzt.

 

[maki]

das ist unnötig, vielleicht gibt es diese Benennung nicht, aber doch offensichtlich Methoden mit und ohne Rückgabewert,
also könnte man die Regeln 'nur einmal return' + 'kein return' problemlos anwenden, zur Verdeutlichung von Funktionen und Prozeduren sprechen,

man muss diese Regeln nicht gut finden, aber strukturell passen sie doch bestens auch in Java..

Was wäre denn besser?
void Methoden jetzt Prozeduren nennen? 😉

Strukturell ist es möglich diese Regeln anzuwenden, gibt aber auch gute Gründe dagegen.

2 return Anweisungen in einer Methode können kürzer & einfacher zu lesen sein als die dekleration, Zuweisung und zurückgeben einer temporären Variablen.

Die Regel "nur ein Return pro Methode" stammt noch aus Zeiten als man sagte "eine Methode darf bis zu einer Bildschirmseite groß sein".
Wenn man eine Methoden 3-5 Zeilen begrenzt macht diese Regel weniger Sinn 😉

Worauf ich hinaus will:
Dinge ändern sich, Regeln die vor 20 Jahren richtig & normal waren darf man heute ruhig nochmals in Frage stellen und in Zusammenhang setzen.

 

[bygones]

Wenn man eine Methoden 3-5 Zeilen begrenzt macht diese Regel weniger Sinn

[ot]er hat Jehova gesagt, er hat Jehova gesagt[/ot]

 

[Andi_CH]

Sowas wie Prozeduren gibt es nicht in Java.

Ach wie heisst es denn? Unterprogramm? Funktion? das sind doch nur Synonyme und Prozedur auch.
In älteren Sprachen hat man das noch unterschieden, was allerdings unnötig war.

Eine Prozedur war ein Unterprogramm ohne Rückgabewert

public void prozedur(){}

und das gibt es in Java sehr wohl

 

[SlaterB]

Strukturell ist es möglich diese Regeln anzuwenden, gibt aber auch gute Gründe dagegen.

2 return Anweisungen in einer Methode können [..]

das scheint mir jetzt wieder Diskussion zu Vor- und Nachteilen der Regel, des Prinzips zu sein,
klingt bisschen anders als das kategorische 'Sowas wie Prozeduren gibt es nicht in Java.'
nun ja, darauf wollte ich hinweisen

ich halte auch nicht viel von dieser Beschränkung, davon abgesehen

 

[maki]

Ach wie heisst es denn? Unterprogramm? Funktion? das sind doch nur Synonyme und Prozedur auch.
In älteren Sprachen hat man das noch unterschieden, was allerdings unnötig war.

Eine Prozedur war ein Unterprogramm ohne Rückgabewert

public void prozedur(){}

und das gibt es in Java sehr wohl

Schon klar, aber "Prozedur" sagt man nicht in Java, damit war klar dass diese Regel von "woanders" kommt 😉

Es gab auch mal "woanders" eine Regel dass man Labels am besten immer groß schreibt, dass man die Übersicht mit den ganzen GOTOs nicht verliert... GOTOs gibt es zwar nicht mehr in Java (das Schlüsselwort ist nur reserviert aber nicht belegt), dafür aber Labels, sollte man die jetzt ständig verwenden, aber dafür immer groß schreiben?

Ansonsten sagt man in Java "Methode" 😉

 

[tfa]

Ach wie heisst es denn? Unterprogramm? Funktion? das sind doch nur Synonyme und Prozedur auch.
In älteren Sprachen hat man das noch unterschieden, was allerdings unnötig war.

Eine Prozedur war ein Unterprogramm ohne Rückgabewert

public void prozedur(){}

und das gibt es in Java sehr wohl

In Java redet man von Methoden. Und wenn du deine for-Schleife in eine Methode auslagerst, die dann nur 3 bis 5 (meinetwegen auch 6 bis 8) Zeilen lang ist, darfst du sie mit return (oder sogar break) verlassen, ohne dass es irgendwie hässlich oder unübersichtlich wird. Darum geht es doch bei der Verwendung dieser Quasi-Gotos.

 

[irgendjemand2]

GOTOs gibt es zwar nicht mehr in Java (das Schlüsselwort ist nur reserviert aber nicht belegt

ähm ... stimmt so nicht ganz ... labels und goto anweisungen kann man in java sehr wohl verwenden *auch wenn das wenig sinn macht* ... es macht halt nur niemand ...

*man kann mit labels z.b. in verschachtelten loops eine bestimmte eben mit ihrem label via [c]break LABEL;[/c] direkt abbrechen .. ohne in höheren eben darauf prüfen zu müssen ob in unteren ebenen abgebrochen wurde ... aber das wird dann ziemlich dirty .. auch wenns funktioniert und der comiler da bestimmt noch i-was rum-optimiert

@TO
in java heißt es einfach schlicht METHODE ... die anderen fachbegriffe stammen aus anderen sprachen ...

und was an einem break so unschön sein soll das man dann ein loop in eine SUB-methode auslagert nur um dort dann return zu verwenden ... das wird mir nicht ganz klar ...

 

[maki]

ähm ... stimmt so nicht ganz ... labels und goto anweisungen kann man in java sehr wohl verwenden *auch wenn das wenig sinn macht* ... es macht halt nur niemand ...

Ach mensch, warum siehst du nicht erst nach bevor hier mal wieder etwas falsches schreibst?

*gespannt bin auch Java Code mit goto Anweisung*

 

[HimBromBeere]

Ich fasse das Ganze mal zusammen, um de Frage wieder die richtige Richtung zu verleihen: es gibt zu dem genannten break keine Alternativen abgesehen von dem Auslagern in eine eigene Methode (oder ich habe sie nur übersehen). Da du aber sowieso deine feste Meinung über die Ästhetik von break innerhalb von Schleifen hast, warum fragst du dann eigtl.?