Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
in der informatik heißt "oder" wenn eins oder beide richtig sind; entgegen der deutschen umgangssprache da wird oder als "entweder oder" gedeutet (xor)
Wenn es geht verwende ich bei while-Schleifen immer folgendes Konstrukt:
Code:
while(true)
{
// Abbruchbedingung für die Schleife
if( iSumme == 1 || iSumme == 4 )
{
break; // Abbruch der Schleife
}
...
}
Man kann sofort erkennen, unter welchen Bedingungen die Schleife abbricht und muß nicht raten, unter welcher Bedingung die Schleife fortgeführt wird (wie bei while(bedingung) ).
Sorry das ich dir das sagen muss, aber das ist dämlich. Jeder der mehr als 2 Tage Programmiererfahrung hat versteht Schleifen und die Verwendung eines zusätzlichen if Konstrukts ist für niemanden nachvollziehbar :shock:
@Wildcard
Es mag nicht deinem Programmierstil entsprechen, aber dämlich ist deswegen noch lange nicht. Wenn du den Ausdruck des OPs besser lesen kannst, als den Ausdruck in meinem if, herzlichen Glückwunsch. Ich glaube, daß man meine Abbruchbedingung (die als solche auch sehr gut gekennzeichnet wurde) beim ersten Lesen verstehen kann, die originale Bedingung zur Fortsetzung der Schleife nicht.
Was glaubt ihr denn, wie der Compiler die Sachen übersetzt? Ich behaupte, daß im nativen Bytecode kein Unterschied zu sehen sein wird!
Wie Slater schon schreibt hast du damit erfolgreich die while Schleife eliminiert.
Offensichtlich bist du es nicht gewöhnt im Team zu arbeiten, denn da sind solche Kunstgriffe überhaupt nicht gern gesehen.
Das Problem fängt schon an wenn du plötzlich merkst das du noch eine weitere Schleife um das while brauchst.
Dann musst du nämlich plötzlich Sprungmarken einführen, und dann wird's noch hässlicher.
Mit breaks spielt man nicht :noe:
Nicht für den Programmfluss, sondern für den Benutzer.
Du wirst zugeben müssen das ein break in einer verschachtelten Schleifenstruktur kein selbsterklärendes Konstrukt ist.
naja, das break springt ans Ende der Schleife,
das ist nicht unübersichtlicher als die Schleifenbedingung wenn man 1 Min. mal drüber nachdenkt
aber wozu, macht nur unnötige Mühe, bringt keinen Nutzen,
Fehler sind schwerer zu erkennen weil man umdenken muss,
gerade diese Umkehrung: statt ok-Bedingung nun Abbruch-Bedingung ist eine exteme Umstellung
die Verschiebung der Bedinung in das if (hoffentlich in die Zeile direkt dahinter!) ist ein zweiter, davon unabhängiger Punkt,
ist auch ungewöhnlich und damit ungünstig
Für Erklärungen gibt es Kommentare, unkommentierten Code einer komplexen Anwendung, ist ohnehin schwer verständlich. Ich wende mein Konstrukt immer dann an, wenn der Ausdruck nach dem if einfacher zu lesen ist, als er nach dem while zu lesen wäre. Ein while(iterator.hasnext()) z.B. braucht man nicht mehr zu vereinfachen. Wenn man neben dem Schleifenabbruch noch etwas anderes machen möchte (zB in ein Logfile schreiben), kommt man um das while(true) sowieso nicht mehr herum.
Code sollte immer selbsterklärend sein (Kommentare gehören natürlich trotzdem dazu)
Yzebär hat gesagt.:
Wenn man neben dem Schleifenabbruch noch etwas anderes machen möchte (zB in ein Logfile schreiben), kommt man um das while(true) sowieso nicht mehr herum.
Code kann gar nicht immer selbsterklärend sein (vor der Realität verblasst so manche Theorie). while(true) macht an vielen Stellen Sinn, du solltest dich mal in der freien Welt umsehen, z.B. wenn erst nach einer Berechnung feststeht, ob die Schleife abgebrochen werden soll und man zwischendurch noch Daten von sonstwoher holen muß (Datenbank, Datei etc.).
Ähh... hallo?! Natürlich ist a || b sehr einfach, doch man sollte nicht vergessen, daß sich hinter a und b beliebig komplizierte Ausdrücke verbergen können, nicht wahr?
Code:
while( value != 1 && value != 4 )
{
...
}
ist für mich schwieriger zu lesen als
Code:
while( true )
{
if( value == 1 || value == 4 )
break;
...
}
zumal die Abbruchbedingung genau so da steht, wie sie ursprünglich lautete, ohne komplett negiert zu werden. Wenn ich "fremden" Code (also den meiner Kollegen) warten muß, bin ich dankbar für jeden Ausdruck, den ich nicht erst mühsam negieren muß, auch wenn diese Schreibweise einen kleinen "Stilbruch" darstellt. Ich möchte wetten, daß der erste Codeschnipsel beim ersten flüchtigen Hinsehen häufiger fehlinterpretiert wird, als der zweite.
Wie gesagt, ich mache es nur, wenn ich der Meinung bin, daß es die Lesbarkeit erhöht (diese Einschätzung ist natürlich subejktiv). Das hat nichts mit Vorliebe zu tun, denn ich schreibe gewöhnlich den Code nicht für mich selbst und kann auch nicht davon ausgehen, daß nur ich für Änderungen an diesem Code zuständig bin.
Die while-Schleife wird im allgemeinen verwendet, wenn etwas ausgeführt werden soll, solange sich die Maschine in einem bestimmten Zustand befindet. Dieser Zustand kann sogar vor Eintritt in die Schleife nicht erreicht sein. Das Abbrechen mit if ist, wie eben gezeigt, einfach eine do-while-, oder besser gesagt, eine repeat-until-Schleife: Man macht irgendetwas und erst hinterher guckt man mal nach, ob der Zustand dieser Maschine überhaupt zulässig war.
Man sollte sich wohl besser mit Begriffen wie Definitionsbereich und Wertebereich auseinandersetzen. Denn diese if-Konstrukte haben starke Ähnlichkeiten mit folgendem „Programmierstil“:
Code:
public int div(int a, int b){
int e=a/b;
if(b==0) throw new IllegalArgumentException(
"Wozu ist eine ArithmeticException da?");
else return e;//wozu ist das else da?
}
Hier ist genau das gleiche Problem: Wir müssen vorher absichern, dass sich die Maschine in einem Zustand befindet, für den unsere nächste Aktion definiert ist (und nicht hinterher :roll: ).
In Java sollte man das Prüfen auf erfüllte Abbruchbedingungen umgehen und stattdessen auf erfüllte Laufbedingungen setzen. Kein einziges Konstrukt in Java möchte wissen, wann es etwas nicht tun soll, sondern wann es etwas tun soll! Jedes if, assert, while, do while usw. will wissen, ob etwas getan werden soll, und nicht, ob etwas nicht getan werden soll.
Das ist nicht ganz richtig. Denn ich kann vor UND nach dem if etwas machen. Ich kann sogar etwas machen, prüfen, machen, prüfen...
Deine Aussagen bezüglich der Methode div sind sicher nicht verkehrt, doch nehmen wir mal ein anderes Beispiel. Wir haben ein String, der als Connectionstring zur Herstellung einer Verbindung zur Datenbank benutzt wird. Wie willst vor dem Aufruf der Methode connect(String connectionstring) feststellen, ob der Connectionstring gültig ist? Du kannst prüfen, ob er null ist oder leer, aber du kannst nicht feststellen, ob er mir ermöglicht eine Verbindung zur Datenbank herzustellen.
Zwei kleine Beispiele aus der weiten quelloffenen Javawelt, die zeigen, daß while(true) durchaus sinnvoll ist:
Code:
while (true) {
final int data = super.read();
final char ch = (char) (data & 0xff);
if (data == -1) {
break;
}
nread++;
if (ch == '\n') {
break;
}
public static boolean isDescendingFrom(Component a, Component b)
{
while (true)
{
if (a == null || b == null)
return false;
if (a == b)
return true;
a = a.getParent();
}
}
