goto-befehl in delphi?

[Oxmyx]

Zitat von Hansa:

Das zeigt, wie unsinnig das Ganze war / ist. Das eine mal ist auch unsinnig. 8) Die GOTO Konzepte gehen zurück in die Zeit nach dem 2. Weltkrieg. Also, was soll die Frage ?

Wenn auf sachlicher Ebene nichts mehr hilft, muss man sich wohl in solche Phrasen stürzen. Wie schon in Beispielen gezeigt, kann Goto helfen, unübersichtliche Bedingungen zu entzerren und Kontrollflags zu vermeiden. Ich habe noch keinen einzigen sachlichen Grund dafür gelesen, was genau daran schlecht ist. Stattdessen lese ich nur Phrasendrescherei.

[omata]

Meine Güte,
was für ein überflüssiger Thread.

folgende Befehle sind überflüssig: exit, goto, break das sind Befehle, die nicht zu einer strukturierten Programmierung gehören. Das ist nun mal so. da kommt man nicht drum herum. Natürlich kann man alles irgendwie hinwurschteln. Aber warum? warum nicht gleich ordentlich und strukturiert programmieren?
Der Computer führt nichts anderes als Sprungbefehle aus, aber eben auf Assemblerebene. Wenn man also die nicht strukturierten Befehle benutzen möchte, sollte man in Assembler programmieren, dann braucht man auch keine höhere Programmiersprache wie Delphi.

So, jetzt könnt ihr wieder weiter rumnörgeln. Ich kann nur wieder holen, denke nach und programmiere überlegt, dann werden auch keine Sprungbefehle wie exit, break und goto benötigt. Man braucht sie nicht und fertig.

Gruss
Thorsten

[Luckie]

Zitat von omata:

folgende Befehle sind überflüssig: exit, goto, break

Und was wenn ich eine Prozedur habe, bei der ich an einem betsimmten Punkt nicht weitermachen kann? OK, einer mag ja noch gehen. Aber wie sieht es bei drei oder mehr aus? Find dich da mal in den verschachtelten ifs und elses zurecht.

Code:

if Belegnummer = 0 then
  exit
if Belegdatum = 0 then
  exit
if x = 0 then
  exit
if y = 0 then
  exit

Mach das mal mit ifs. Viel Spass, wenn du nach einem halben Jahr den Code warten musst. Mit dem Exits entspricht es genmau dem Programmablaufplan.

[omata]

Das ist negative Logik. So sollte man nicht programmieren. Wie wäre es mit positiver Logik?

Wie gesagt exit ist nicht nötig und blödsinn.

Gruss
Thorsten

[Dax]

Zitat von Luckie:

Code:

if Belegnummer = 0 then
  exit
if Belegdatum = 0 then
  exit
if x = 0 then
  exit
if y = 0 then
  exit

Delphi-Quellcode:

if not ((Belegnummer = 0) or (Belegdatum = 0) or (x = 0) or (y = 0)) then
begin
  ...
end;

[Luckie]

Ging nicht, weil immer eine andere Fehlermeldung kommen musste.

[Oxmyx]

Zitat von omata:

Das ist negative Logik. So sollte man nicht programmieren. Wie wäre es mit positiver Logik?

Wie gesagt exit ist nicht nötig und blödsinn.

Gruss
Thorsten

Du hast eine Funktion, der ein oder mehrere Parameter übergeben werden. Falls die übergebenen Parameter nicht innerhalb eines gewissen Gültigkeitsbereichs liegen, kann die Funktion nicht arbeiten und muss gleich wieder abgebrochen werden. Wie machst du das denn?

[JasonDX]

Zitat von omata:

folgende Befehle sind überflüssig: exit, goto, break das sind Befehle, die nicht zu einer strukturierten Programmierung gehören. Das ist nun mal so. da kommt man nicht drum herum. Natürlich kann man alles irgendwie hinwurschteln. Aber warum? warum nicht gleich ordentlich und strukturiert programmieren?
Der Computer führt nichts anderes als Sprungbefehle aus, aber eben auf Assemblerebene. Wenn man also die nicht strukturierten Befehle benutzen möchte, sollte man in Assembler programmieren, dann braucht man auch keine höhere Programmiersprache wie Delphi.

So, jetzt könnt ihr wieder weiter rumnörgeln. Ich kann nur wieder holen, denke nach und programmiere überlegt, dann werden auch keine Sprungbefehle wie exit, break und goto benötigt. Man braucht sie nicht und fertig.

Wenn du keine Sprungbefehle in Hochsprachen verwenden willst, frag ich mich, wie du ohne diese eine switch-Anweisung in C# überleben willst

Meine Meinung ist folgende: Eine generelle Behauptung "dieser Befehl/Anweisung ist überflüssig/sinnlos" ist nicht haltbar. Wenn sie überflüssig und sinnlos ist, hätte sie nicht über 30 Jahre überlebt.
Ein Goto ist natürlich immer sehr umstritten. Es führt durch falsche Verwendung (weitaus leichter als ein break oder ein exit) zu unleserlichem Code - und ist gerade deswegen sehr verpöhnt. Das bedeutet allerdings nicht, dass es an manchen Plätzen keine Berechtigung hat.
Natürlich kann man auch Code, Prozeduren, Schleifen ect. ohne Sprungbefehle schreiben, ich kann eine Prozedur auch mit einer einzigen Variable implementieren, aber bestimmte Befehle und Anweisungen existieren, um mir als Programmierer das Leben zu erleichtern. Und ich sehe keinen Grund, mir extra Arbeit aufzudrücken zu müssen, wenns auch einfacher mit dem selben Ergebnis geht.

greetz
Mike

[Luckie]

Zitat von omata:

Das ist negative Logik. So sollte man nicht programmieren. Wie wäre es mit positiver Logik?

Code:

if Belegnummer <> 0 then
begin
  if BelegDatum <> 0 then
  begin
    if x <> 0 then
    begin
     if y <> 0 then
     begin
     end
     else
       Fehlermeldung
    end
    else
      Fehlermeldung
  end
  else
    Fehlermeldung;
end
else
  Fehlermeldung

Sehr übersichtlich, wenn in jedem Block noch 10 Zeilen Code stehen Wenn ich das Exit im Code sehe, dann weiß ich, dass ich mir den Rest nicht mehr angucken muss und muss mir nicht erst 30 Zeilen tiefer das zugehörige else suchen, um zu gucken, was stattdessen passiert.

[omata]

Zitat von Luckie:

Ging nicht, weil immer eine andere Fehlermeldung kommen musste.

Für solche Fälle gibt es Exceptions.

Zitat von Oxmyx:

Du hast eine Funktion, der ein oder mehrere Parameter übergeben werden. Falls die übergebenen Parameter nicht innerhalb eines gewissen Gültigkeitsbereichs liegen, kann die Funktion nicht arbeiten und muss gleich wieder abgebrochen werden. Wie machst du das denn?

Da überlegt man sich den positiven Fall (nicht den Negativen), hab ich ja oben schon geschrieben.

Zitat von JasonDX:

Wenn du keine Sprungbefehle in Hochsprachen verwenden willst, frag ich mich, wie du ohne diese eine switch-Anweisung in C# überleben willst

Wir reden hier von Delphi. Wenn eine Programmiersprache keine Möglichkeiten für eine strukturierte Lösung bietet, dann bleibt einem wohl nichts übrig, als unstrukturiert zu programmieren.

Gruss
Thorsten