Zitat von
R2009:
ich habe noch keinen Fall gesehen indem man goto verwenden müsste!
Ich auch nicht, aber die hier gezeigten Alternativen viel schlimmer.
Zitat von
R2009:
Ansonsten: Alle Jahre wieder kommt das "goto" Kind!
Das ist gut so, denn wie Du siehst, lohnt die Diskussion. Viele Programmierer brechen sich lieber einen ab, als ein GOTO zu verwenden.
Zitat von
omata:
Da reichen vier Buchstaben: Nein
Wie kannst Du das verneinen? Das ist eine Tautologie!
"Wenn ich weiss, was ich tue, mache ich keine Fehler." Der Satz ist so banal wie: "Wenn es regnet, wird die Erde naß". Den kann man nicht verneinen.
Zitat von
omata:
...auf krampf ein Beispiel konstruieren, ...
Wo siehst Du hier den Krampf? Mir scheint, Du wurdest in deiner Kindheit von herumlungernden GOTO's verprügelt, anders ist deine Aversion nicht zu erklären. Lies doch nochmal den Threadanfang: Michael stellt eine Behauptung auf und lädt zur Diskussion ein. Persönlich und diffamierend muss man da nicht werden, auch wenn man als Bub von GOTO's gequält wurde. Wie sagtest Du so schön, das ist bedauernswert
Zitat:
...und echt traurig.
Zitat von
himitsu:
Delphi-Quellcode:
function DemoThread(p: Pointer): Integer;
...
if Abort then begin
SendMessage(ParentHandle, CM_ABORT, 0 , 0);
Break;
end;
SendMessage(ParentHandle, CM_STATUS, Integer(PChar('Durchlauf:')), i);
Sleep(500);
if i = 9 then SendMessage(ParentHandle, CM_FINISHED, 0, 0);
end;
Dispose(p);
Result := 0;
end;
Das soll lesbarer sein? Dieser Code ist Vieles, aber eines sicherlich nicht: Lesbarer. Und intuitiv zu erfassen ist er auch nicht, denn ich muss mir erst überlegen, was die komische IF-Anweisung in der Schleife soll. Die wird bei jedem(!) Schleifendurchlauf ausgeführt, nur um beim letzten Mal (und nur dann!) TRUE zu liefern. Uneffizienter und Umständlicher kann man kaum kodieren. Und das alles nur, um ein GOTO zu vermeiden? Nebenbei ein eklatanter Verstoß gegen das DRY-Prinzip: Die zentrale Bedingung (max. N Versuche) ist an zwei Stellen im Code).
In diesem Thread geht es nicht darum zu zeigen, wie man ein GOTO vermeidet (ich unterstelle Michael mal, das er weiss, wie das geht), sondern um die Frage, ob Code mit einem GOTO nicht manchmal lesbarer wird!
Der zweite Versuch von Dir ist ein Paradebeispiel für Codeencryption
.
Delphi-Quellcode:
...
while (i <= 9) and not Abort do ...
Ich verwende diese While-Schleife immer wieder gerne als Beispiel, wieso ein Sprung (Break, Exit, und die Verwendung einer eigenen Funktion) sinnvoller ist, als das umständliche Hantieren mit Schleifen und Abbruchbedingungen.
Zitat:
Und ja, ich finde auch, daß es an einigen Stellen einfach einfacher mit GOTO lösbar ist.
Ah
Ich behaupte aber mal als Konsequenz (um auch eine Brücke zu omata zu schlagen):
1. Jedes einigermaßen nachvollziehbare GOTO springt aus einer Schleife heraus. Andere sinnvolle Verwendungen gibt es nicht.
2. Jede Schleife kann in eine Funktion (SRP) verfrachtet werden, wodurch das GOTO durch ein EXIT ersetzt werden kann.
3. Ergo kann man GOTO streichen, ohne die Lesbarkeit des Codes zu verschlechtern.
4. Im Umkehrschluss
kann Code lesbarer werden, wenn kein GOTO verwendet wird.
(4) Gilt aber nicht automatisch und immer, wie man an den vielen Alternativen hier gesehen hat!
So, und wer nun kein Anhänger des 'Clean Code' ist und nicht immer Bock hat, jede Pupsschleife in eine eigene Funktion zu packen, nur um ein GOTO zu vermeiden, der soll in Gottes Namen sein GOTO verwenden. Davon geht die Welt nicht unter. Der Code bleibt effizient und vor allem wesentlich lesbarer, als jeder krampfhafte Versuch, mit Flags und While-Schleifen ein GOTO zu vermeiden.