for-Schleife gegen über while-Schleife

[Satty67]

Zitat von jaenicke:

Die Verschwendung von Rechenzeit und Arbeitsspeicher ist heute nicht mehr so schlimm wie früher

Da fällt mir noch ein schönes Zitat ein:

"Die Hardware wird nicht so schnell schneller, wie Software langsamer wird."

[omata]

Vielen Dank, das du mir unterstellst, langsamen und ineffizienten Code zu schreiben. Meine Anwendung sind super schnell und doch hoch komplex, ich hatte bis jetzt keine Probleme. Aber, wenn du meinst.
IE, Chrome und Opera finde ich einfach schlecht und versuche da einen großen Bogen drum zu machen. Das einzig brachbare ist für mich in Sachen Browser der Firefox.
Also wir sind da komplett gegensätzlich, scheinen aber trotzdem beide keine Probleme zu haben. Das finde ich sehr interessant, es zeigt, das scheinbar alles egal ist.

[jaenicke]

Zitat von omata:

Vielen Dank, das du mir unterstellst, langsamen und ineffizienten Code zu schreiben.

Welchen Code du sonst schreibst, weiß ich nicht. Ich rede nur von dem, um den es hier geht.
Und hier ist while eben in der direkten Umsetzung ohne extra Variable usw. ineffizienter und langsamer.

Zitat von omata:

Das einzig brachbare ist für mich in Sachen Browser der Firefox.

Wenn er schneller starten würde als er es tut, würde ich ihn auch gerne nutzen. So ist er für mich unbrauchbar.
Trotzdem wollte ich darüber gar nicht über Browser diskutieren, deshalb sage ich dazu nichts weiter, mir waren nur gerade IE und FF als erstes eingefallen als ich ein Beispiel für langsame Software schreiben wollte.

[omata]

Und ich schüttel weiter mit meinem Kopf wenn ich deine Zeilen lese. Einfach unfassbar... naja wie auch immer ich sage da jetzt auch nichts mehr zu.

[Hansa]

Warum fragst Du nach selber nicht überprüften Zitaten ?

Zitat von Satty67:

Was steht in Clean Code zum Thema strukturierte Programmierung und Break?

Dort wird die bisherige Regel, niemals break und continue zu verwenden deutlich relativiert:

Zitat von Robert C. Martin 'Clean Code, aus Kapitel 3.11 dt. Ausgabe':

Wenn Sie Ihre Funktionen klein halten, dann richtet eine gelegentliche Anwendung von mehreren return-, break- oder continue-Anweisungen keinen Schaden an und kann den Code manchmal ausdrucksstärker machen, als die Ein-Eingang-Ein-Ausgangs-Regel.

Da steht im Kern : gelegentliche und manchmal Da sage ich nur : jo, indead, kann im Ausnahmefall vielleicht was bringen.

Zitat von Satty67:

Da fällt mir noch ein schönes Zitat ein:

"Die Hardware wird nicht so schnell schneller, wie Software langsamer wird."

Bei dir vielleicht. Wie hat Bill Gates gesagt ? "640 kB reichen"

[Luckie]

Zitat von Hansa:

aber was wenn eine ein paar hundert Zeilen hätte ? Und mittendrin wird noch eine eigene Funktion aufgerufen, die Exit & Co. benutzt

Dann solltest du erstmal den Code aufräumen, denn dann hast du schon viel früher was falsch gemacht. Und eine aufgerufene Funktion, die Exit aufruft, stört meine Funktion nicht.

[Satty67]

Zitat von Hansa:

Warum fragst Du nach selber nicht überprüften Zitaten ?

Verstehe nicht ganz, was ich vorher hätte prüfen sollen? Ich hab' das recht kleine Kapitel 3.11 nochmal komplett gelesen, bevor ich zitiert hab'. Was hätte ich sonst machen sollen. Es ging mir auch darum, das die Regeln für strukturiertes Programmieren in Lehrbüchern (also kein break in Schleifen) auch nicht von jedem Autor so streng ausgelegt wird, ganz im Gegenteil.

Zumindest ich hatte die ersten Aussagen so verstanden, das eine Variante Zeit spart und das kann gelegentlich bei großen Schleifen ein wichtiger Vorteil sein. Zu wissen, wie beide Varianten arbeiten, halte ich deshalb für sehr interessant. Es schreibt mir ja auch niemand hier vor, wie ich es machen soll, es bleibt ja mir überlassen. Bisher hab' ich hier im Forum Empfehlungen zum Code-Aufbau bekommen. Das war oft sehr logisch und nachvollziehbar, weshalb ich das auch dankbar übernommen hatte. Ich den meisten Fällen werde ich es aber so schreiben, wie ich es selbst am besten verstehe. Das mach für mich den meisten Sinn

Ich denke die Diskussion hat unnötige Härte bekommen. Ich persönlich glaube einfach, das je nach Situation die eine oder andere Variante Vorteile hat und es manchmal einfach egal ist.

[alzaimar]

Lesbarer Code ist dann lesbar, wenn ihn jemand anderes mit halbwegs gleichem Kenntnisstand versteht.
So?

Delphi-Quellcode:

Function ExistsObjectIn3D (aKey : TSomeType) :  Boolean;
Var
  x,y,z : Integer;
Begin
  For x := 0 to MaxX do
    For y := 0 to MaxY do
      For z := 0 to MaxZ do
        If Space3D[x,y,z] = aKey Then Begin
           Result := True;
           Exit;
        End;
End;

Oder so?

Delphi-Quellcode:

Function ExistsObjectIn3D (aKey : TSomeType) :  Boolean;
Var
  x,y,z : Integer;
  
Begin
  Result := False;
  x := 0;
  While (x <= MaxX) and not Result do 
  Begin
    y := 0;
    While (y <= MaxY) and not Result do 
    Begin
      z := 0;
      While  (z <= MaxZ) and not Result do 
        If Space3D[x,y,z] = aKey Then 
          Result := True;
    End
  End
End;

Ich bevorzuge die erste Variante. Sie ist nahezu selbstdokumentierend.

Für 'Break' findet sich ein ähnliches Beispiel, wobei ich anstatt:

Delphi-Quellcode:

j := -1;
For i:=0 to Foobar Do
   If ValueExists(i) Then Begin
     j := i;
     break;
   End;

If j>=0 Then ...
...

Lieber eine lokale Funktion verwende:

Delphi-Quellcode:

...
  Function _IndexOfValue : Boolean;
  Begin
    For Result := 0 To Foobar Do
       If ValueExists (Result) Then Exit;
    Result := -1;
  End;

Begin
...
  If _IndexOfValue >= 0 Then
...
End;

Bei mir steht *immer* die Lesbarkeit (neben Wartbarkeit und Erweiterbarkeit) im Vordergrund. Das sind für mich die einzig geltenden Regeln. Wenn ein exit einen Code lesbarer macht, nur her damit. Selbst eingoto darf dann verwendet werden. Mir muss der Programmierer nur hinreichend erklären, wieso dieses Konstrukt hinsichtlich der geltenden Regeln (s.o.) die beste Wahl ist.

Und um den Bogen zur Ausgangsfrage zu spannen: Welches Schleifenkonstrukt nun verwendet wird, hängt wiederum von der Aussage ab, die getroffen werden soll. Denn Code hat eine Aussage: Er erklärt, wie ein Problem gelöst wird. Hier drei Lösungsansätze für das Problem: "Richtiges Verhalten zur Nahrungsaufnahme":
(1) While: "Solange Du Hunger hast, iss ein Brot"
(2) For / ForEach: "Für alle Brote: Iss sie auf"
(3) Repeat: "Iss ein Brot, bis du satt bist (keinen Hunger mehr has)"

(1) impliziert, das man keinen Hunger haben könnte,
(2) ignoriert ihn und
(3) verhindert eine Hungersnot.

Welches Konstrukt gewählt werden sollte, hängt also einzig und allein von der Aufgabenstellung ab (Gesunde Ernährung, Mästen, Abwenden von Hungersnöten).

PS: Um (2) zur gleichen Aussage wie (1) zu bewegen, benötigt man das "Break":
(2a) For / ForEach: "Für alle Brote: Iss sie auf, aber wenn Du währenddessen keinen Hunger mehr hast, hör auf".

[Luckie]

Komisch bei folgender Routine hat sich mir irgendwie eine while-Schlaife aufgedrängt. Ich weiß auch nicht warum:

Delphi-Quellcode:

function GetNextLowerPLZFromList(var PLZ: Integer; PLZSunHours: TPLZSunHours): Integer;
var
  i: Integer;
begin
  // Raises EPLZNotInList exception if no lower PLZ can be found
  i := High(PLZSunHours);

  while (PLZ < PLZSunHours[i, 0]) and (i > -1) do
  begin
    Dec(i);
  end;

  if i = -1 then
    Raise EPLZNotInList.Create(rsENotInList);

  PLZ := PLZSunHours[i, 0];
  Result := PLZSunHours[i, 0];
end;

[alzaimar]

Mir drängt sich dabei eher eine For-Schleife auf:

Delphi-Quellcode:

function GetNextLowerPLZFromList(var PLZ: Integer; PLZSunHours: TPLZSunHours): Integer;
var
  i: Integer;

begin
  For i:= High(PLZSunHours) downto 0 do
    If PLZ < PLZSunHours[i, 0] Then Begin
      PLZ := PLZSunHours[i, 0];
      Result := PLZ;
      Exit;
    End;

  Raise EPLZNotInList.Create(rsENotInList);
end;

Ich halte meine Version für verständlicher, da ich keinem erklären muss, wieso bei (i=-1) ein vorzeitiger Abruch der Routine erfolgt. Hier haben wir doch wieder ein Beispiel, das ein 'exit' den Code dezent kompakter und lesbarer macht.

Was habt ihr bloß gegen 'exit', 'break' und 'continue'? Wieso existieren diese Konstrukte auch in modernen Programmiersprachen? Ein Zugeständnis an Rookies? Wohl kaum, denn dann wäre 'goto' auch mit von der Partie.

Sind Exceptions nicht viel schlimmer, da sie ein globales goto repräsentieren, wobei noch nicht mal klar ist, wo das Sprungziel ist?