Verständnisfrage zu Exit

[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.

[venice2]

Zitat:

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

Kein Problem nur warum überhaupt ein "begin"

Delphi-Quellcode:

If Bedingung1 then
  exit
else if Bedingung2 then 
  Mache2
else if Bedingung3 then 
  Mach3
else 
...

zudem würde ich solche Verschachtelungen gar nicht verwenden sondern direkt mit Case arbeiten.

Delphi-Quellcode:

case Bedingung of
  1:
    exit;
  2:
    Mache2;
  3:
    Mache3;
  else
    was auch immer
end;

[HeZa]

Zitat von venice2:

Kein Problem nur warum überhaupt ein "begin"

Da bin ich bei dir. Zur Not könnte man den Code aus den begin-end Blöcken in kleine lokale Proceduren/Funktionen packen.

Zitat von venice2:

zudem würde ich solche Verschachtelungen gar nicht verwenden sondern direkt mit Case arbeiten.

Da es unterschiedliche Bedingungen sein könnten, ist ein case nicht immer möglich.

[mkinzler]

Zitat:

Ich finde die Methode 2 weder böses GoTo noch Spaghetticode oder sonstwas, sondern nur eins: Sehr übersichtlich.

Ich bevorzuge eher begin und end auf selber (Einrückungs-)Ebene.

Zitat:

Kein Problem nur warum überhaupt ein "begin"

Damit man es nicht später vergisst. (wenn dann die Sequenz erweitert wird)

Zitat:

Zur Not könnte man den Code aus den begin-end Blöcken in kleine lokale Proceduren/Funktionen packen.

Warum nur zur Not? Hängt eher vom Unfang/Länge der Sequenz( Block) ab und ob er vielleicht wo anders noch benötigt wird.

[dummzeuch]

Juchu, lasst uns noch eine Diskussion um Goto und Goto-ähnliche Konstrukte führen! Das hatten wir schon lange nicht mehr.

Meine Meinung:
Im Gegensatz zu Continue, Break und einem Goto, ist Exit ein relativ harmloses Konstrukt und hat definitiv seine Anwendung. Insbesondere verwende ich es gern, um am Anfang einer Methode die Eingangs-Voraussetzungen (Parameter, Zustand des Objekts) zu prüfen und die Methode dann zu verlassen, wenn es nichts zu tun gibt.

Delphi-Quellcode:

procedure bla(const _s: string);
begin
  if _s = '' then begin
    // ein leerer String braucht nicht verarbetet zu werden.
    Exit; //==>
  end;
  // irgendwas längeres mit _s machen
end;

oder

Delphi-Quellcode:

procedure TSomeObject.SetVisibiel(_Value: boolean);
begin
  if _Value = FVisible then begin
    // keine Änderung -> raus
    Exit; //==>
  end;

  FVisible := _Value;
  // jetzt noch alles mögliche andere machen
end;

Dieses "Early Return" wird durchaus häufig verwendet, ist aber nicht ganz umstritten.

Dann gibt es noch eine andere praktische Verwendung von Exit: Das frühzeitige Verlassen von Schleifen:

Delphi-Quellcode:

function FindMatchingString(_sl: TStringList; const _s: string; out _Idx: Integer): boolean;
var
  i: Integer;
begin
  for i := 0 to _sl.Count -1 do begin
    if StartsText(_s, _sl[i]) then begin
      _Idx := i;
      Result := True;
      Exit; //==>
    end;
  end;
  Result := False;
end;

Natürlich könnte man da auch Break verwenden, aber die Erfahrung hat mich gelehrt, dass ein Break gerne mal nicht die Schleife beendet, von der man denkt, dass sie beendet wird. Nachdem ich zum x-ten Mal irgendo eine geschachtelte Schleife eingebaut hatte und Break dann plötzlich nur noch diese innere Schleife verlasen hat, habe ich mir komplett abgweöhnt, es zu verwenden. Dito Continue.

Ach ja, und dann gibt es da immernoch das einzige Goto in unserer Codebase, das ich vor 13 Jahren eingebaut habe und jetzt schon aus Trotz drin lassen werde.