"FinalllyExit" gewünscht

[FredlFesl]

Zitat:

Zitat von omata (Beitrag 1097867)

Zitat:

Zitat von FredlFesl (Beitrag 1097865)

:wall: Blödsinn. Diesen Quatsch lese ich nun schon seit Jahren immer wieder.

Ja, weil sich an der Gültigkeit dieser Aussage auch nichts ändert.

Eben. Es war, ist und bleibt Blödsinn.
Dieser Schwachfug ist in Zeiten aufgekommen, als auffiel, das ein GOTO etwas furchtbar Böses ist und ein EXIT (und BREAK) ja eigentlich auch irgendwie ein GOTO bzw. ein Sprung. Und vor lauter Verteufeln hatte man doch glatt vergessen, das das soooo elegante Exceptionhandling nichts Anderes ist, als ein objektorientiertes SetJmp/LongJmp und damit eigentlich auch zu verteufeln wäre.

Aber gut: Vertreter der Gattung "EXIT's sind schlechter Codestil" behaupten das ja grundsätzlich und sind daher nicht in der Lage, dies grundsätzlich zu belegen.

Zitat:

Zitat von Stevie (Beitrag 1097872)

An alle, die jetzt Codeschnippsel produzieren, um von der Nützlichkeit und Unabdingbarkeit von Exit zu überzeugen: Hier habt ihr nen Keks. :lol:

Dann stell nicht solche absurden Behauptungen auf.

[omata]

Zitat:

Zitat von FredlFesl (Beitrag 1097877)

Zitat:

Zitat von omata (Beitrag 1097867)

Zitat:

Zitat von FredlFesl (Beitrag 1097865)

:wall: Blödsinn. Diesen Quatsch lese ich nun schon seit Jahren immer wieder.

Ja, weil sich an der Gültigkeit dieser Aussage auch nichts ändert.

Eben. Es war, ist und bleibt Blödsinn.

Du hast mich falsch verstanden, macht aber nichts.

[Satty67]

Zitat:

Zitat von Aphton (Beitrag 1097873)

Ok, wie es nun aussieht, fällt das in die Kategorie "Geschmackssache".

Fand das eigentlich eine ganz gute Aussage, um der Sache die Schärfe zu nehmen.

Man kann Exit, Goto, With etc. so einsetzen, dass es übersichtlicher wird. Aber man kann mit den genannten Anweisungen auch Chaos in den Code bringen. Deshalb wird wohl davon abgeraten, zumal es fast immer eine Alternative gibt.

Ich kenne wenig Delphi-Code, wo Exit ungünstig eingesetzt wird und ich deshalb rätseln musste wie eine Funktion arbeitet. Als ich mit C# angefangen hatte, hat mich das inflationär eingesetzte return oft viel Zeit gekostet. Bei Delphi bn ich doch immer wieder froh, dass man von Haus aus etwas strengere Regeln anlegt (auch wenn es manchmal etwas übertrieben sein mag)

[Stevie]

Zitat:

Zitat von FredlFesl (Beitrag 1097877)

Zitat:

Zitat von omata (Beitrag 1097867)

Zitat:

Zitat von FredlFesl (Beitrag 1097865)

:wall: Blödsinn. Diesen Quatsch lese ich nun schon seit Jahren immer wieder.

Ja, weil sich an der Gültigkeit dieser Aussage auch nichts ändert.

Eben. Es war, ist und bleibt Blödsinn.
Dieser Schwachfug ist in Zeiten aufgekommen, als auffiel, das ein GOTO etwas furchtbar Böses ist und ein EXIT (und BREAK) ja eigentlich auch irgendwie ein GOTO bzw. ein Sprung. Und vor lauter Verteufeln hatte man doch glatt vergessen, das das soooo elegante Exceptionhandling nichts Anderes ist, als ein objektorientiertes SetJmp/LongJmp und damit eigentlich auch zu verteufeln wäre.

Aber gut: Vertreter der Gattung "EXIT's sind schlechter Codestil" behaupten das ja grundsätzlich und sind daher nicht in der Lage, dies grundsätzlich zu belegen.

Zitat:

Zitat von Stevie (Beitrag 1097872)

An alle, die jetzt Codeschnippsel produzieren, um von der Nützlichkeit und Unabdingbarkeit von Exit zu überzeugen: Hier habt ihr nen Keks. :lol:

Dann stell nicht solche absurden Behauptungen auf.

Als erstes solltest du dich wieder etwas beruhigen. Ich geb dir auch ne Tasse Tee oder Kaffee zum Keks aus 8-)

Meine Meinung zu dem Thema ist folgende (die darf ich ja noch haben und auch kund tun, oder? vielen Dank):
Da in Delphi das Statement

Delphi-Quellcode:

Result := xyz;

nunmal nicht so wie in anderen Sprachen

Delphi-Quellcode:

return xyz

das direkte Verlassen der Routine zur Folge hat und danach weitergarbeitet wird/werden kann, hat man mit dem Benutzen von Exit 2 verschiedene Verhaltensweisen: die "herkömmliche" (Abarbeiten der Routine bis zum Ende) und das direkte Verlassen (mit oder ohne Rückgabewert). Benutze ich die herkömmliche Weise, kann ich sicher sein, dass sich alles immernoch genauso verhält, wenn ich weiteren Code hinzufüge (z.B. Objekt freigeben, Logging Eintrag, etc). Das ist bei einem Exit nicht so. Es verändert den gewohnten Ablauf (im Sinne von 1 Eingang und 1 Ausgang), indem es einen weiteren Ausgang aus der Routine schafft.

Ja, richtig, hier prallen wieder mal die unterschiedlichen Ansichtsweisen, was sauberer Code ist und was nicht, aufeinander. Ich stehe nach wie vor zu meiner Meinung und ich werde auch an irgendeiner Stelle wo es "nötig ist", von den 0.01% der Fälle Gebrauch machen und ein Exit einsetzen. Aber in keinem der hier im Thread erwähnten Fälle.

[himitsu]

Break und Exit haben nunmal ihre Berechtigung und auch ich nutze sie sehr oft.
Genauso wie das super GOTO wird manchmal verwendet.
(ich wünsche mir auch noch ein GOSUB)

Ja, wenn man ganz pervers ist, dann verwendet man auch noch Exceptions, zur Steuerung des Programmablaufs.
Und Timer, sowie ProcessMessages für langanhaltende Programmteile, anstatt von Threads.


So, jetzt dürft ihr mich steinigen.
ich steh dazu, daß ich Exit und auch manchmal Goto verwende, vorallem wenn sich dadurch der Programmablauf vereinfachen oder übersichtlicher gestalten läßt.

[Aphton]

Pass auf, dass du nicht gesteinigt wirst. Du läufst hier die Gefahr...
Du hast es ja eh selbst schon befürchtet xD

[sx2008]

Wenn man Exit richtig einsetzt erhöht das die Lesbarkeit; wenn man es falsch einsetzt verringert man die Lesbarkeit.
Es geht also nicht um die Anzahl der Zeilen oder Optik sondern um die Lesbarkeit.

Nach meiner Erfahrung gilt es dabei zu beachten:

1.) wenn man Exit verwendet, dann möglichst frühzeitig aussteigen

Delphi-Quellcode:

procedure GoodExample1(arg1,arg2,..);
begin
  if arg1 = arg2 then
    Exit;
  // hier folgen einige weitere Anweisungen
  Anweisung1;
  ...
  AnweisungN;
end;

2.) Exit nicht verwenden, wenn man gezwungen wäre Anweisungen zu wiederholen

Delphi-Quellcode:

procedure BadExample2(arg1,arg2,..);
begin
  Machwas;
  if (IrgendeineBedingung) then
  begin
    MachNochIrgendwas;  // doppelter Code
    Exit;
  end;
  // hier folgen einige weitere Anweisungen
  .....
  MachNochIrgendwas;  // doppelter Code
end;

3.) Exit nur einmal verwenden
Wenn man an mehreren Stellen eine Funktion/Procedure mit Exit verlässt,
dann verschlechtert dies die Lesbarkeit.

4.) Exit aus einer Schleife
Hier zeigt sich ganz klar der Vorteil von Exit; man kann eine Schleife und zugleich
die Funktion/Procedure verlassen, ohne dass der der Schleife folgende Code ausgeführt wird.
Man spart sich so die Verwendung eines boolean Flags.

5.) Exit in "Kleinfunktionen"
Manchmal wird Exit verwendet, ohne wirklich eine Verbesserung der Lesbarkeit zu bringen.
Das zeigt sich z.B. in Funktionen mit nur ganz wenigen Anweisungen

Delphi-Quellcode:

function BadExample2(arg..):Boolean;
begin
  result := False;
  if EineBedingung then
    Exit;   // sehr unschön
  EineEinzigeWeitereAnweisung;
  Result := True;
end;

Dies lässt sich so umschreiben (und man spart sogar eine Zeile):

Delphi-Quellcode:

function GoodExample2(arg..):Boolean;
begin
  result := not EineBedingung;  // anstatt "not" besser die Bedingung umformulieren
  if Result then
    EineEinzigeWeitereAnweisung;
end;

Mit diesem Kochbuch kann eigentlich in Bezug auf Exit nichts mehr schiefgehen.
So und nun habt euch wieder lieb!!

[Namenloser]

Zitat:

Zitat von sx2008 (Beitrag 1097917)

Wenn man Exit richtig einsetzt erhöht das die Lesbarkeit; wenn man es falsch einsetzt verringert man die Lesbarkeit.
Es geht also nicht um die Anzahl der Zeilen oder Optik sondern um die Lesbarkeit.

Genau so ist es. Ich setze Exit und Break ein, wo es sinnvoll ist. Ich habe sogar letztens zum ersten mal seit 5 Jahren oder so mal wieder ein Goto verwendet, weil – ihr werdet es nicht glauben – es den Code erheblich vereinfacht hat.

Das:

Zitat:

Zitat von FredlFesl

Delphi-Quellcode:

i := 1;
Aborted := False;
While (i <= N) and not Aborted Do
Begin
  j := 1;
  While (j <= M) and Not Aborted Do
  Begin
    If Bla[i,j].HasInvalidData() Then
      Aborted := True
    Else
    Begin
      Bla[i,j].Process();
      ...
      Inc(J)
    End;
  End;
  Inc(i);
End;

ist einfach nicht übersichtlicher als das:

Zitat:

Zitat von FredlFesl

Delphi-Quellcode:

For i:=1 to N Do
  For j := 1 to M Do
  Begin
    If Bla[i,j].HasInvalidData() Then Exit;
    Bla[i,j].Process();
    ...
  End;

Egal wie oft man es behauptet. Ich habe so ähnliche Dinger wie das obere Beispiel (Danke, FredlFesl) tatsächlich schon ein paar mal gesehen und jedes mal Krämpfe bekommen.

Sicher gibt es auch genau so gute Beispiele wie man seinen Code mit Exits und Breaks verhunzen kann.

Es kommt eben immer auf das richtige Maß an. Alles mit Scheuklappen auf eine vorgebene Weise zu machen ist übrigens auch ein Anti-Pattern:

Zitat:

Golden hammer: Assuming that a favorite solution is universally applicable

[Stevie]

Zitat:

Zitat von NamenLozer (Beitrag 1097921)

Egal wie oft man es behauptet. Ich habe so ähnliche Dinger wie das obere Beispiel (Danke, FredlFesl) tatsächlich schon ein paar mal gesehen und jedes mal Krämpfe bekommen.

Vielleicht sollte man sich bei dem Beispiel aber auch Gedanken darüber machen, ob man überhaupt HasInvalidData überprüft und nicht einfach eine Exception im Process wirft, wenn dies der Fall ist und das in einem Block außen um die beiden Schleifen behandelt und dementsprechend einen Rückgabewert setzt. Is nämlich sonst für den Aufrufer dieser Routine ziemlich bescheiden, wenn er nicht weiß, ob nun alles Processed ist oder obs irgendwo ausgestiegen ist, weil HasInvalidData true war.

Dazu sag ich dann nur:

Zitat:

Zitat von Aphton (Beitrag 1097873)

wenn man mal Quick & Dirty auf saubere Art und Weise programmieren will, ist das geeignet

[Namenloser]

Zitat:

Zitat von Stevie (Beitrag 1097924)

Zitat:

Zitat von NamenLozer (Beitrag 1097921)

Egal wie oft man es behauptet. Ich habe so ähnliche Dinger wie das obere Beispiel (Danke, FredlFesl) tatsächlich schon ein paar mal gesehen und jedes mal Krämpfe bekommen.

Vielleicht sollte man sich bei dem Beispiel aber auch Gedanken darüber machen, ob man überhaupt HasInvalidData überprüft und nicht einfach eine Exception im Process wirft

Ja, da magst du recht haben, hab mir das Beispiel nicht soo genau angeschaut, aber es gibt schon recht häufig Fälle, wo man verschachtelte Schleifen hat und aus mehreren raus muss, auch wenn kein Fehler auftritt. Z.B. wenn man in einem Baum einen Knoten sucht o.ä..