Sinnvoller Einsatz von goto

[R2009]

Hi,

auch mein Senf dazu:
ich habe noch keinen Fall gesehen indem man goto verwenden müsste!
Auch noch so mühsam konstruierte Fälle kann man mit den üblichen Konstrukten abfangen.

Ansonsten: Alle Jahre wieder kommt das "goto" Kind!

Grüsse
Rainer

[alzaimar]

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.

[Deep-Sea]

Noch mal eine Kleinigkeit, die ggf. gegen ein Goto spricht: Da es nicht in allen Sprachen existiert (z.B. in Java), lässt sich ein Quelltext mit Goto schlechter in solche Sprachen portieren, weil man den Code dazu verstehen (was natürlich immer von Vorteil ist) und auch ändern muss
(Klar, euch kann es egal sein, ob andere Programmierer die einen guten Code gerne auf "ihre" Sprache portieren möchten sich dazu abplagen müssen oder nicht ...)

[Wolfgang Mix]

Wikipedia meint:

Zitat:

Pascal unterstützt in seiner Urform keine Anweisungen, mit denen Prozeduren
oder Schleifen hart verlassen werden können. Als strukturerhöhendes goto
werden Sprünge ans Ende von Prozeduren oder unmittelbar hinter Schleifenenden
akzeptiert, sofern sich dadurch umfangreiche Konstruktionen schlecht
lesbarer if-Anweisungen oder undurchschaubarer boolescher Ausdrucke
vermeiden lassen. Viele Pascal-Compiler erlauben keine goto, die zu instabilen
Systemzuständen führen, z. B. der Sprung in den Anweisungsblock einer Schleife
oder eines if.

Dieses Beispiel habe ich im Handbuch von TP 5.5 gefunden. Passt wunderbar zum Thema
Lösung quadratischer Gleichungen mit der Hochzeitsformel, wenn a 0 ist.

Delphi-Quellcode:

VAR A,B,C : Integer;
Label : Ende;
Begin
  Anweisungen ...
  Readln(A);
  If (A=0) Then Goto Ende;
  Anweisungen ...
  Ende: {Hier ist das Label Ende}
  Writeln('Hier ist wirklich Schluß');
End.

Dann löst das 'mal komplizierter ...

[Deep-Sea]

Zitat von Wolfgang Mix:

Delphi-Quellcode:

VAR A,B,C : Integer;
Label : Ende;
Begin
  Anweisungen ...
  Readln(A);
  If (A=0) Then Goto Ende;
  Anweisungen ...
  Ende: {Hier ist das Label Ende}
  Writeln('Hier ist wirklich Schluß');
End.

Delphi-Quellcode:

VAR A,B,C : Integer;
Begin
  Anweisungen ...
  Readln(A);
  If A <> 0 then 
  begin
    Anweisungen ...
  end;
  Writeln('Hier ist wirklich Schluß');
End.

Oder wie oder was???

[DeddyH]

IIRC gab es in TP < 7 weder break noch exit, daher waren gotos die einzige Möglichkeit, aus einer Schleife herauszuspringen. Ansonsten stört mich weder break, exit noch goto, wenn es sinnvoll und spärlich eingesetzt wird und der Lesbarkeit dient. So, die ewig Gestrigen können mich jetzt meinetwegen steinigen.

[edit] Kleine Korrektur: eine Möglichkeit gab es doch mit dem Einsatz einer Boolschen Variablen, die gesetzt werden konnte, um die Schleife zu verlassen, aber das war doch ziemlich umständlich IMO [/edit]

[Progman]

Programmieren ist eine Tätigkeit, die schöpferisch und sehr individuell von Statten geht.
Jeder hat Vorlieben oder Aversionen auf Grund seiner Erfahrung, was die Codierung betrifft. Und niemand muss sich zu irgendwelchen "Programmier-Stil-Standards" zwingen lassen.
Also soll doch bitteschön niemand meckern, wenn jemand in bestimmten Situation auch zu "verpönten" Befehlen wie Goto, Exit, Break, Halt usw. greift. Die Hauptsache ist, dass das Programm fehlerfrei läuft. Den Anwender interessiert es herzlich wenig, was im Quell-Code steht.

[Luckie]

Zitat von Progman:

Die Hauptsache ist, dass das Programm fehlerfrei läuft.

Nein auch Wartbarkeit spielt eine Rolle. Und damit ein Code wartbar ist, muss er lesbar und möglichst leicht verständlich sein. Ein wildes hin und her Gespringe mit goto und ähnlichen Konstrukten, ist da eher kontraproduktiv.

[Matze]

Zitat von Progman:

Und niemand muss sich zu irgendwelchen "Programmier-Stil-Standards" zwingen lassen.

Das stimmt auch nicht ganz. Wenn der Arbeitgeber einen Styleguide festlegt, dann muss man sich daran halten.
Ist dort festgelegt, dass ein "goto" nicht verwendet werden darf, ist man gezwungen, dieses auch nicht einzusetzen.

[Progman]

Zitat von Luckie:

Zitat von Progman:

Die Hauptsache ist, dass das Programm fehlerfrei läuft.

Nein auch Wartbarkeit spielt eine Rolle. Und damit ein Code wartbar ist, muss er lesbar und möglichst leicht verständlich sein. Ein wildes hin und her Gespringe mit goto und ähnlichen Konstrukten, ist da eher kontraproduktiv.

An wildes hin- und hergespringe habe ich da eigentlich nicht gedacht. Aber es sind Konstrukte denkbar, wo Code mit einem Goto wesentlich besser lesbar (und wartbar) ist als künstliche Verrenkungen, nur um kein Goto zu verwenden. Aber das wurde hier ja auch schon gesagt
Und dass ein Arbeitgeber vorgibt, in welchem Stil programmiert werden muss, hab ich noch nie gehört.
Es gibt meist Vorgaben für die Software (was sie können muss, wie sie aussehen und gestaltet sein soll etc.).
Dem Auftraggeber ist es meist sogar egal, in welcher Sprache gearbeitet wird. Hauptsache seine Vorgaben werden erfüllt.
Wir machen Software, die verkauft werden soll und nicht, welche um den besten Programmierstil wetteifert. Das intrweressiert den Käufer nicht die Bohne *g*