Verständnisfrage zu Exit

[Benmik]

Zitat von Delphi.Narium:

Wenn ich schon mit Exit rausspringe, kann ich mir die nachfolgende Else sparen.

Das sehe ich anders. Wenn ich einen (und womöglich längeren) Streifen mit else oder end else if habe, dann weiß ich sofort, dass nur einer dieser Blöcke ausgeführt wird. Bei deiner Notation springt dies nicht ins Auge, vielmehr erfährt man erst durch Auswerten, dass der nachfolgende Code nicht ausgeführt wird. Das empfinde ich als deutlich weniger intuitiv.

[Delphi.Narium]

Aber in der Situation ist das Exit nicht (zwingend) erforderlich, da die Routine ohne das Exit zum gleichen Ergebnis führen würde.

Schreibtechnisch wird also ein Result := 1 durch Exit(1) ersetzt.
Da finde ich die Zuweisung des Rückgabewertes an Result deutlich intuitiver als ein Exit, auch wenn es letztlich zum gleichen Ergebnis führt.

Exit nutze ich persönlich nur, wenn ich in 'ner Fehlersituation (also im Exceptblock eines Trys) aus 'ner Routine raus muss und damit sicherstellen will, das, egal, was später noch in 'ner Routine implementiert wurde, die Routine beendet wird.

Aber in 'ner If-else-if-Kasskade mit Exit auszusteigen, obwohl die Logik so implemtiert ist, dass das Exit nicht erforderlich ist, find' ich persönlich eher befremdlich.

Delphi-Quellcode:

function Test : Integer;
begin
  if a then begin
    Exit(1);
  end else
  if b then begin
    Exit(2);
  end else
...
  if z then begin
    Exit(26);
  end;
  // Jahre später wird in der Routine eine Änderung nötig, z. B. sowas:
  if (Result > 20) and (Result < 23) then begin
    // Mit Exit haben wir nun ein Problem, vor allem dann, wenn es nicht so offensichtlich ist, wie hier im Beispiel.
    // Mit der Nutzung von Result wäre es aber kein Problem.
  end;
end;

Und:

Wenn man Code nur intuitiv betrachtet und daraus Schlüsse zieht, kann man schonmal deutlich schiefliegen. Da ziehe ich die grundsätzliche Auswertung des Quelltextes doch vor.

Oder das ganze mal mit Case:

Delphi-Quellcode:

function Test(i : Integer) : Integer
begin
  case i of
    1      : Exit(1);
    2.. 10 : Exit(2);
   11..100 : Exit(3);
  else
    Exit(42);
  end;
end;

statt:

Delphi-Quellcode:

function Test(i : Integer) : Integer
begin
  case i of
    1      : Result := 1;
    2.. 10 : Result := 2;
   11..100 : Result := 3;
  else
    Result := 42;
  end;
end;

Geht beides, Variante 2 ist mir da aber deutlich lieber.

[TurboMagic]

Zitat von Der schöne Günther:

Result in C++? Meinst du return ?

Wie auch immer, gegen deinen Code spricht nichts. Außer dass du auch stattdessen schreiben könntest Exit(1) .

Aber nur, wenn er von seinem Delphi 6 auf was neueres umsteigt.

[himitsu]

"Logisch" sind ELSE eigentlich passend,
auch wenn beim EXIT das ELSE unnötig wäre.

Wenn man aber mit ELSE und nur Result:= arbeitet, dann hat man z.B. die Chance ans Ende "einen" Haltepunkt zu setzen oder eine Loggingfunktion dort einzufügen, was bei den Exits (zentral) nicht ginge.


Was ich heute in der Hilfe vom VBScript sah .... im Delphi braucht man zum Glück nicht mehr Funktionsname := ...; und kann fehlerunanfäliger mit Result arbeiten. (sogar lesend)

[Uwe Raabe]

Zitat von himitsu:

Wenn man aber mit ELSE und nur Result:= arbeitet, dann hat man z.B. die Chance ans Ende "einen" Haltepunkt zu setzen oder eine Loggingfunktion dort einzufügen, was bei den Exits (zentral) nicht ginge.

Das Exit springt aber doch an das end der Function. Dort kannst du doch den Haltepunkt setzen.

[himitsu]

Nicht immer.
Keine lokalen Variablen und Dergleichen und schon kann Exit auch direkt rausspringen.

[Uwe Raabe]

Zitat von himitsu:

Keine lokalen Variablen und Dergleichen und schon kann Exit auch direkt rausspringen.

Hier geht es:

Delphi-Quellcode:

function MyFunc(Value: Integer): Integer;
begin
  if Value = 1 then
    Exit(1);
  if Value = 2 then
    Exit(2);
end;

[Medium]

Irgendwie habe ich den Eindruck, dass bisher im Thread die eigentliche "Gefahr" von Exit, mit oder ohne Return-Wert komplett übersehen wurde: Exit ist im Grunde nichts anderes als ein "goto" mit einem Label direkt vorm Methodenende. Exit begünstigt schlicht Spaghetti-Code, und erlaubt das Verlassen von Methoden/Funktionen/Prozeduren an Stellen, an denen es die sonstigen Kontrollstrukturen nicht offensichtlich erahnen lassen. Es ist einfach ein Wartbarkeits- bzw. Lesbarkeitsproblem, kein technisches oder logisches.

Ich persönlich nutze es nur gelegentlich, und dann auch nur gesammelt in den allerersten Zeilen einer Methode, wo ich gelegentlich abprüfe ob alle Bedingungen zur weiteren Verarbeitung der Methode gegeben sind. Und auch das meist nur in Legacy-Codes, wo eine wirklich "saubere" Lösung sehr unwirtschaftliche größere Restrukturierungen bedeuten würden. Und ich fühle mich schmutzig dabei.
Eine weitere Ausnahme sind Mini-Prozeduren, die aus maximal 10-15 Zeilen bestehen, die nur sehr kleine Aufgaben übernehmen. In diesen ist wenig genug Code, dass ein Exit nicht so leicht im allgemeinen Gewimmel untergeht, und gelegentlich zu weniger verschachteltem und besser lesbarem Code als die sonst nötigen Strukturen führt.

Rein technisch gesehen wäre es in 100% der Fälle vermeidbar; diese DIskussionen sind meiner Meinung nach hinfällig.

[Delphi.Narium]

Exit ist für mich im Großen und Ganzen ein Zeichen von unstrukturierter Programmierung, aber sicher kein empfehlenswerter Programmierstil. Les- und Wartbarkeit leiden, für meine Begriffe, extrem.

[Benmik]

Zitat von Medium:

...in den allerersten Zeilen einer Methode, wo ich gelegentlich abprüfe ob alle Bedingungen zur weiteren Verarbeitung der Methode gegeben sind.

Ganz genau. Klassische Beispiele sind If Dateiname = '' oder If not TFile.Exists(Dateiname) da geht man einfach raus und das ist gut so. Auch ein GoTo ist nicht in 100% der Fälle schlecht, sondern nur in 99%, und in diesem einen Prozent macht es den Code besser und nicht schlechter, egal was der Pfarrer sagt. Zum Beispiel, wenn man aus verschachtelten Schleifen herausspringt, wenn ein bestimmtes Ergebnis auf kompliziertem Weg gefunden wurde. Kein Mensch kann mir erzählen, dass es einen gestandenen Programmierer in Verwirrung stürzt, wenn am Ende einer Schleife ein Label Weiter: oder Nächster Durchlauf: oder MachsNochEinmalSam: steht. Es sind eher die Verrenkungen, die man betreibt, um zu beweisen, dass es auch mit der ganz ganz reinen Lehre geht, die den Code schlechter machen. Mein ich aus meiner bescheidenen Amateursicht.

Wenn man hier schon der Hohepriesterei der Lesbarkeit und Übersichtlichkeit huldigt, warum hält dann die ganze Delphizunft an diesem unsäglichen

Delphi-Quellcode:

If Bedingung1 then
  begin
    Mach1;
  end
else
if Bedingung2 then
  begin
    Mach2;
  end
else
  begin
    MachNix;
  end;

fest?
Man vergleiche das mit

Delphi-Quellcode:

If Bedingung1 then begin
  exit;
end else if Bedingung2 then begin
  Mach2;
end else if Bedingung3 then begin
  Mach3;
end else begin
...
end;

Kein Mensch, wirklich keiner, würde auf die Idee kommen, das anders zu machen, wenn man nicht in eine Zunft reinkäme, die nunmal darauf geeicht ist.
Mit Genugtuung sehe ich immer, dass ausgerechnet David Heffernan es auch auf die zweite Weise macht, und hier gilt das für Thomas Müller (dummzeuch) ebenso. Heffernan geht so weit, dass er überhaupt kein einfaches "then" mehr benutzt, sondern ausschließlich "then begin". Jetzt ist nicht alles richtig, nur weil David Heffernan es so macht, aber offensichtlich kann man auch so lesbaren und guten Code schreiben. Jedenfalls warte ich noch auf den Tag, an dem einer aufsteht und David mal Bescheid sagt.

Ich finde die Methode 2 weder böses GoTo noch Spaghetticode oder sonstwas, sondern nur eins: Sehr übersichtlich. Es spielt - in meinen Augen - überhaupt keine Rolle, dass das "end else" nach dem "exit" technisch nicht notwendig ist: Na und? Man sieht auf einen Blick: Es gibt da 3 oder 5 oder auch 8 Zustände, die zu 3 oder 5 oder 8 Reaktionen führen, einer oder meinetwegen auch 3 oder 7 davon bedeuten "exit". "Exit" ist eine völlig legitime Konsequenz, was daran schlecht oder gar schmutzig sein soll, erschließt sich mir nicht so ganz.

Jetzt habe ich mich ein bisschen ereifert, da bitte ich um Nachsicht.