goto-befehl in delphi?

[Luckie]

Zitat von omata:

und nunmal ohne exit...

Code:

fehler:='';
if Belegnummer = 0 then 
  fehler:='Fehler: Belegnummer'
else if Belegdatum = 0 then 
  fehler:='Fehler: Belegdatum'
else if x = 0 then 
  fehler:='Fehler: x'
else if y = 0 then 
  fehler:='Fehler: y';

if fehler = '' then
  // mache was, es ist alles ok
Result:=fehler;

Das geht nicht. Wenn ich keine Belegnummer habe, kann ich kein Belegdatum ermitteln. Sprich, wenn ich die Belegnummer nicht habe, kann ich nicht weiter machen. Nächster Vorschlag bitte.

[Daniel]

Zitat von Hansa:

Mann mann, sogar mit Moderatorenhilfe werden Argumente gegen eine strukturierte Programmierung gesammelt. Ich glaub ich bin im falschen Film.

Den Eindruck habe ich allerdings auch.
Es ist zu unterscheiden, ob Michael in seiner Rolle als Moderator etwas zu diesem Thema schreibt oder in seiner Rolle als Delphi-Entwickler.


Aber diese gesamte Diskussion ist hinfällig. Es geht um wartbaren Code und niemand konnte bisher darlegen, dass ein exit quasi per se schlechten Code erzeugt. Alles, was man hier als Negativbeispiel liest, sind grausige Anwendungsfälle von Sprungbefehlen - aber mal ehrlich: Grausame Sachen kann ich auch mit Variablen oder gar Klassen realisieren, ganz in der vermeintlich hübsch strukturierten Welt.

Guter Code entsteht nicht automatisch durch den Verzicht von Sprungbefehlen und auch umgekehrt wird guter Code nicht zwingend zu schlechtem Code, wenn man dort ein wohlplatziertes "exit" findet.

[Ultimator]

Zitat von Hansa:

Was ist eigentlich mit objektorientierter Programmierung ?

Mann mann, was hat denn jetzt objektorientierte Programmierung mit der Verwendung von goto zu tun?
Ich kann auch in meinen Objektmethoden ein goto verwenden.
Um den ganzen Aufstand um die "an den Haaren herbeigezogenen Codebeispiele" mal zu beruhigen: Ist es denn so schwer, einfach mal zuzugeben, dass ein goto in manchen Fällen wirklich sinvoll ist? Aber nein, man muss (wie es z.B. bei Luckies Code war) mit aller Gewalt versuchen, die gotos aus dem Code zu eliminieren, wobei man ihn auf die etwa eineinhalbfache Länge streckt und dabei noch verkompliziert.

[Jasocul]

Delphi-Quellcode:

fehler:='';
  if Belegnummer <> 0 then
    if Belegdatum = 0 then
      fehler:='Fehler: Belegdatum'
    else
      if x = 0 then
        fehler:='Fehler: x'
      else
        if y = 0 then
          fehler:='Fehler: y'
  else
    fehler:='Fehler: Belegnummer';
  if fehler = '' then
    // mache was, es ist alles ok
  Result:=fehler;

Ob der Code nun besser oder schlechter ist, sei mal dahingestellt.
Man kann alles ohne Goto lösen und ich mache das auch. Mit richtigen Einrückungen sehe ich auch sofort, wo ich weiter lesen muss, wenn eine Bedingung nicht erfüllt ist. Sowas kann ich nicht als Argument für Goto gelten lassen.
Bisher hatte ich noch keine Verwendung für ein Goto. In Basic habe ich auch schon programmiert. Dort habe ich es allerdings verwendet.
Break habe ich auch schon verwendet, allerdings muss ich schon sehr übrelegen, wann es das letzte mal war. Continue habe ich genau einmal verwendet, weil ich für eine Testprozedur einfach zu faul war, die Schleife umzustellen. Das einzige, was ich gelegentlich mal verwende, ist exit. Immer dann, wenn ich in einer Testphase gewisse Bereiche im Source aussparen möchte.
Wer so starke Verschachtelungen hat, dass es nicht mehr überschaubar ist, sollte sich über die Nutzung von Funktionen mal Gedanken machen.

Ich benötige bisher kein goto. Wer es nutzen will, soll es machen. Allerdings sollte man sich bei einer Team-Programmierung (oder wenn andere den Source bearbeiten müssen) sehr genau überlegen, wie intensiv das Goto genutzt wird. Sollte ich irgendwann die Notwendigkeit sehen, dass ich es nutzen muss, werde ich es auch machen. Aber ich werde es vermeiden, wenn sinnvoll möglich.

[richard_boderich]

selbst unter basic hab ich vieles mit GOSUB und RETURN erledigt und auf ein goto verzichten koennen.
ich hab in meiner ganzen delphi zeit nich ein goto verwendet. nur einmal bei nem alten turbo pascal programm. und auch nur weil es nicht anders ging (geschachtelte schleife verlassen)

die aussage ueber positive logic halte ich fuer unsinnig. wenn sich die gleiche programmfunktion mit weniger code bzw. lesbarerem code realisierbar ist, verwende ich durchaus auch negative logic
vom code her gesehn gebe ich luckies variante eindeutig den vorzug. aber ist nur meine persoenliche meinung. soll jeder machen wie erst fuer richtig haelt.

richard

[Der_Unwissende]

Hi Leute,
ihr seit echt mega OT. Als jmd. der mal gerade alle Beiträge gelesen hat, möchte ich sagen ihr dreht euch schon etwas im Kreis.
Fazit bisher, es gibt Sprungbefehle verschiedener Art und alle können benutzt werden oder nicht.
Es lässt sich doch hier eh keiner bekehren, ob ihr jetzt noch so pseudo-sachlich kommentiert oder nicht.

Egal wie man programmiert, an dem bedingten Sprung kommt doch letztlich der Assembler gar nicht vorbei. Wie schön wäre es denn für die CPUs, wenn es nie zu einem Sprung käme, dass ne Menge Geld in die Vorhersagbarkeit fließt spricht mindestens auf der Ebene für das goto. Und somit wird schon jede Sprache die inline Assembler unterstützt nicht ums goto rum kommen.
Wie jedes Sprachfeature bleibt es aber dem Programmierer überlassen es zu verwenden. Ob man dies übersichtlich an wenigen o der unübersichtlich an vielen Stellen macht hat doch nichts mit dem Befehl an sich zu tun.
An dieser Stelle sei auch erwähnt, dass nicht alle C Programme in einer Zeile stehen, nur weil es Menschen gibt die solche Programme erstellen.

Der Satz, dass einem an der Uni gesagt wird man darf ein goto nicht verwenden (oder sollte es meiden) ist auch sehr sehr weit hergeholt. Wer soll einem dass den sagen? Ich meine du hast da sicherlich nicht den Kurs "Programmieren allgemein und in allen Sprachen". Es gibt wie gesagt Sprachen, da kommt man gar nicht um ein Label mit Sprung rum, da es keine Alternativen gibt. Zudem möchte die Uni (zumindest keine die ich kenne) einen nicht eine spezielle Sprache lehren. An der Freien Universität Berlin sind im Moment Veranstalltungen in Haskell, Java (J2SE und J2EE), C, C# und Prolog am laufen (das sind die von denen ich weiß). Was jetzt also noch an weiteren Sprachen dort gelehrt wird, wer weiß. Da die Studenten all diese Kurse früher oder Später besuchen könnten nutzt ihnen die Kenntnis einer Sprache einfach nichts. Hat man die Grundlagen hingegen verstanden, ist der Rest nur noch Syntax. Deshalb wird an Universitäten sehr abstrakt gelehrt, da kann also keiner Sprachbezogen von einem Sprung abraten (wie gesagt ist man nur maschinennah genug geht das gar nicht anders).

Gruß Der Unwissende

[mkinzler]

Jetzt fehlt nur noch die obligatorische Umfrage-Option anderer Foren. Dann können sich hier 2 Gruppen bilden, die nicht mehr miteinander Reden, bis eine Seite zugibt sich geirrt zu haben.

[OregonGhost]

Zitat:

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?

An der FH hat ein Professor mir beigebracht, dass und warum man immer strukturiert programmieren soll. Er hat der Vollständigkeit halber die entsprechenden C-Sprachkonstrukte erklärt (also return, goto, break, continue), aber auch, dass man sie niemals benutzen darf, außer natürlich im switch (in C# ist das break dort ein Teil der Syntax und kein echter Sprungbefehl).
Aber das ganze hatte einen Hintergedanken - man sollte die Programme nicht nur als Code, sondern auch als Struktogramm zeichnen können. Habt ihr das mal gemacht? Eine der unsinnigsten Erfindungen, die es gibt, in meinen Augen. Genauso sinnlos wie zigfach verschachtelte Ifs und Thens zu verwenden, anstatt sie zu umgehen. Sobald man nämlich eine Exception (das ist doch ein Feature moderner Sprachen? ) verwendet, ist nix mehr mit strukturiert im klassischen Sinne. Dann springt man nämlich sofort raus. Sogar noch brutaler als mit einem break oder goto. Man weiß innen nämlich nichtmal, wo man landet, denn vielleicht fängt die aufrufende Methode die Exception ab, vielleicht wird sie auch über zig Ebenen nach oben gereicht.
Also, Exceptions benutzt man, aber goto nicht, und nichtmal break oder continue?
Fahrt ihr auch nicht in PKWs mit, weil man damit Menschen umfahren kann, aber in Bussen schon?

Die Tatsache, dass man mit einem Sprachkonstrukt (einer Klasse aus eine Laufzeitbibliothek, einem Programm...) immensen Schaden anrichten kann, als Vorwand zu nehmen, das Konstrukt niemals zu verwenden, ist ideologisch vielleicht sinnvoll, praktisch aber unsinnig. Darf ich niemals einen Treiber schreiben, nur weil ich mit einem Treiber Windows XP zu einem Bluescreen bringen könnte?

Ach, und noch eine Ergänzung zum Thema OOP. Schonmal gemacht? Code bleibt Code, egal ob ich in einer Methode bin und meine Variablen alle Objekte sind statt fundamental. Es sind immer noch Funktionsaufrufe, immer noch Ifs und Thens und Schleifen, und immer noch Sprungbefehle. Insofern macht es für diese Diskussion keinen Unterschied, ob man objektorientiert oder prozedural programmiert.
Hmm, und dann noch, man soll das Zeug nicht verwenden, weil es so jung ist Oo
Iteratoren, Generics und Nullable Types gibt es in C# erst ab der Version 2.0 - darf ich sie jetzt nicht verwenden? War ja ursprünglich nicht vorgesehen...

[Michael Habbe]

@Jasacul

Du hattest da einen Fehler drin.

Delphi-Quellcode:

fehler:='';
if Belegnummer <> 0 then
  fehler:='Fehler: Belegnummer'
else
  if Belegdatum = 0 then
    fehler:='Fehler: Belegdatum'
  else
    if x = 0 then
      fehler:='Fehler: x'
    else
      if y = 0 then
        fehler:='Fehler: y'
      else
        ; // mache was, es ist alles ok, kein Fehler aufgetreten

result := fehler;

@luckie

Da wird der Code auch nur ausgeführt, wenn kein Fehler auftritt. Beim ersten Fehler verlässt er die weiteren Vergleiche. Ist vielleicht mehr Tipparbeit, aber bei weitem übersichtlicher als innerhalb von 15 ifs mit Exit zu antworten.

[DIET3RIX]

Zitat von OregonGhost:

Aber das ganze hatte einen Hintergedanken - man sollte die Programme nicht nur als Code, sondern auch als Struktogramm zeichnen können. Habt ihr das mal gemacht? Eine der unsinnigsten Erfindungen, die es gibt, in meinen Augen.

Genauso seh' ich das auch, so wurde mir das auch auch ma beigebracht.