for-Schleife gegen über while-Schleife

[Luckie]

Delphi-Quellcode:

if not ende then 
  ende := not (i < length(SonnenStundenListe) - 1); 
while not ende do begin

Drei nots hintereinander. Schlimmer geht es glaube ich nicht mehr. Welhen Wert hat denn jetzt das ende in der whle-Schleife? Wenn es true ist, hast du eine Endlosschleife.

[jaenicke]

Zitat von oki:

Bis jetzt wurde nur von gutem Stil und lesbarkeit gesprochen. Eine fachliche Begründung hab ich noch nicht gesehen (oder überlesen).

Es geht dabei auch nur um Stil und Lesbarkeit, nicht um Logik oder Performance des Programms. Die bessere Logik und Performance wird dabei absichtlich geopfert.

Rein vom erzeugten Assemblercode her wäre for + Break in vielen Situationen sauberer.

Ich persönlich setze daher die am besten passende, optimalste und performanteste Lösung ein, nicht eine realitätsfernere aus einem Lehrbuch.

[oki]

Zitat von jaenicke:

Zitat von oki:

Bis jetzt wurde nur von gutem Stil und lesbarkeit gesprochen. Eine fachliche Begründung hab ich noch nicht gesehen (oder überlesen).

Es geht dabei auch nur um Stil und Lesbarkeit, nicht um Logik oder Performance des Programms. Die bessere Logik und Performance wird dabei absichtlich geopfert.

Rein vom erzeugten Assemblercode her wäre for + Break in vielen Situationen sauberer.

Ich persönlich setze daher die am besten passende, optimalste und performanteste Lösung ein, nicht eine realitätsfernere aus einem Lehrbuch.

Da gehts mir jetzt aber wieder besser. Ich benutze Breaks eigentlich eher in recht kurzen Schleifen. Unübersichtlich sind die eigentlich eher nicht und verwirrt haben sie mich auch noch nie. Aber ich will hier nicht gegen den anerkannten Style reden.

Gruß oki

[omata]

Zitat von jaenicke:

...nicht eine realitätsfernere aus einem Lehrbuch.

Blödsinn.

Schade, das es keinen Smily mit Kopfschütteln gibt.

[Hansa]

Zitat:

Welhen Wert hat denn jetzt das ende in der whle-Schleife? Wenn es true ist, hast du eine Endlosschleife.

Du mussst die ... beachten. 8) Gewöhne dir das Break/Exit nur an, aber mit dem Risiko, dass es eventuell (je nachdem wers sieht) als Design-Fehler gewertet wird. Im Gegensatz zu Delphi-Warnungen/Hinweisen kann das im Wiederholungsfall aber dann letztenendes als Error gewertet weden ! C'est la vie. Hier gehts ja momentan nur um 10-Zeilen Schleifen, aber was wenn eine ein paar hundert Zeilen hätte ? Und mittendrin wird noch eine eigene Funktion aufgerufen, die Exit & Co. benutzt ? Selbst wenn man die im Verdacht hätte, dann genügt leider nicht mehr eine einzelne Stelle um Breakpoint, showmessage zu benutzen um unliebsame Effekte einzugrenzen, sondern man müsste die diversen Exits, Breaks... separat behandeln.

[omata]

Um es mal in einem Wort zu sagen: so etwas nennt man unstrukturierte Programmierung und exit, goto, break, ... sind nunmal unstrukturiert. Ich programmiere gern in einer höheren Programmiersprache und nutzte deshalb auch die Vorzüge strukturierter Programmierung. Genau aus dem Grund sind nunmal gewisse Befehle einfach nicht existent. Man braucht sie einfach nicht, sie sind einfach überflüssig.

[jaenicke]

Zitat von omata:

Zitat von jaenicke:

...nicht eine realitätsfernere aus einem Lehrbuch.

Blödsinn.

Das ist doch so. Was ich machen will ist, mir alle Einträge der Reihe nach nach einem bestimmten Kriterium anzuschauen. Und aufgrund eines bestimmten (unbestimmt eintretenden, ich weiß das ja vorher nicht, ob es eintritt) Ereignisses kann ich mir den Rest ersparen und daher schon vorher abbrechen. Das ist die Logik dahinter.

Das kann ich jetzt umbauen, indem ich von vorneherein davon ausgehe, dass dieses Ereignis (der Fund) eintritt und ich daher wahrscheinlich gar nicht alles durchsuchen muss.

Mir ist jedenfalls wichtiger, dass ein Programm schnell alles korrekt erledigt, als dass das Programm immer wieder kurz nachdenkt oder schon langsam startet, weil sich der Programmierer an irgendwelche starren Regeln gehalten hat.

Das erinnert mich irgendwie an das 18. Jahrhundert als z.B. die Kapitäne und Admirale der englischen Marine durch die Regeln der Seekriegsführung an bestimmte Vorgehensweisen gebunden waren, auch wenn diese die fast sichere Niederlage bedeuteten.

Und warum soll man extra umständlich mit while arbeiten, wenn Delphi die Optimierung eigentlich mit for selbst macht? for, eine Zeile:

Delphi-Quellcode:

for i := 0 to Length(SonnenStundenListe) - 1 do
  ...

while, äquivalenter Code:

Delphi-Quellcode:

MyArrayLength := Length(SonnenStundenListe);
i := 0;
while (i < MyArrayLength) do 
begin

  Inc(i);
end;

Dazu kommt dann in beiden Fällen noch die andere Bedingung. Wofür soll man den Delphiquelltext derart aufblähen. Das macht das ganze erst recht unübersichtlich.

Zitat von Hansa:

Hier gehts ja momentan nur um 10-Zeilen Schleifen, aber was wenn eine ein paar hundert Zeilen hätte ?

Dann hat man im Regelfall einen Fehler gemacht. Normalerweise modularisiert man Code entsprechend.
Und dokumentiert natürlich auch so weit, dass der Code nachvollziehbar ist.

[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.

[omata]

Für mich ist das nicht umständlich. Ich war noch nie Tippfaul und ob ich da nun eine Zeile spare ist nicht relevant für mich. Ich versuche strukturiert zu Programmieren. Deshalb sind die erwähnten Befehle nicht existent. Sie sind auch nicht nötig. Wenn man ohne sie nicht auskommt ist das ja ok, aber man programmiert dann eben nicht strukturiert, zumindest nicht an den Stellen, an denen man diese unstrukturierten Sprungbefehle benutzt.
Nach der Kompilierung wird ja sowieso alles zu Sprüngen und Vergleichen umgesetzt. Aber das ist ja gerade der entscheidene Vorteil einer Hochsprache, das man strukturell Programmieren kann. Will man das nicht, kann man genauso gut auch gleich in Assemblercode programmieren, den kann man dann auch hoch optimieren. Für mich geht es um das Lösen von komplexen Problemen und da interessiert mich nur die innere Schönheit und somit stabile Erweiterbarkeit von Systemen. Und diese Rubustheit erhält man nunmal eher, wenn man auf Strukturierte Programmierung setzt.
Wie gesagt, wer das nicht kann bzw. nicht will soll das so machen wie er will. Aber ich frage mich dann immer, warum soll ich mir so einen überflüssigen Blödsinn merken, wenn es auch ohne geht? Ich brauche nicht drüber nach zudenken, ob ich da jetzt ein exit setzt oder nicht. Da es für mich nicht existiert, stellt sich die Frage nicht.

Und dein tolles Kommentar, mit der vermeintlich Altertümlichen-Nicht-Dazu-Lernenden-Art ist quatsch, weil genau die Befehle, über die wird gerade diskutieren aus dieser Vergangenheit kommen. Also ein Starrsinn und Nicht-Dazu-Lernen ergibt sich hier nur, wenn man diese immer noch einsetzt.

@Satty67: ja ok, dabei liegt die Betonung aber auf gelegentlich. Also im Umkehrschluss nicht immer! Also nach dem Motto es gibt auch was anderes und es ist nicht notwendig und wie ich weiter oben ja schon geschrieben habe: Ausnahmen bestätigen die Regel. Ausnahmen!

[jaenicke]

Zitat von omata:

Will man das nicht, kann man genauso gut auch gleich in Assemblercode programmieren, den kann man dann auch hoch optimieren. Für mich geht es um das Lösen von komplexen Problemen und da interessiert mich nur die innere Schönheit und somit stabile Erweiterbarkeit von Systemen.

Fragt sich dann nur was man mit einem schön geschriebenen aber langsamen und damit kaum benutzbaren Programm dann anfängt.

Der Internet Explorer 8 hat z.B. schöne Ideen und ich würde ihn sehr gerne einsetzen. Leider ist er aber so langsam, dass er für mich unbrauchbar ist. Ebenso der Firefox.

Die Verschwendung von Rechenzeit und Arbeitsspeicher ist heute nicht mehr so schlimm wie früher, aber absichtlich gar nicht zu optimieren finde ich trotzdem schlecht.