"FinalllyExit" gewünscht

[himitsu]

Ja.
Ich glaub seit 2010/2009.

Wie gesagt, ich fordere ja schon lange und nicht umsonst eine Kennzeichnung in der OH, seit wann es was gibt, so wie man es z.B. aus dem MSDN kennt.

[omata]

Zitat:

Zitat von Zacherl (Beitrag 1097858)

Grade wenn man viele APIs hintereinander aufruft und immer wieder die Rückgabe prüft, dann hat man ohne Exit spätestens nach der 4.-5. Verschachteltung viel Spaß den Code sauber einzurücken :D

Dafür gibt es eine Tastenkombination (Strg + Shift + U/I).

[Zacherl]

Zitat:

Zitat von omata (Beitrag 1097863)

Zitat:

Zitat von Zacherl (Beitrag 1097858)

Grade wenn man viele APIs hintereinander aufruft und immer wieder die Rückgabe prüft, dann hat man ohne Exit spätestens nach der 4.-5. Verschachteltung viel Spaß den Code sauber einzurücken :D

Dafür gibt es eine Tastenkombination (Strg + Shift + U/I).

Das ist nicht das Problem, aber wenn man sich an die vorgegebene Zeilenlänge hält, wirds unschön ..

[FredlFesl]

Zitat:

Zitat von Stevie (Beitrag 1097847)

Mag nur meine Meinung, aber für jedes Exit sollte es einen Schlag in den Nacken geben.
Klar, an manchen Stellen kann man sich in etwas vertrackten Konstrukten einfach aus der Affaire ziehen, aber sauber gecoded ist es zu 99.99% vermeidbar.

:wall: Blödsinn. Diesen Quatsch lese ich nun schon seit Jahren immer wieder.
Wenn ein EXIT unsauber wäre, dann gilt das auch für Exceptions.
Auch verstehe ich nicht, wieso es in allen modernen Programmiersprachen so ein Konstrukt gibt. Wenn das unsauber oder veraltet wäre, würde man das doch wegkürzen, so wie Goto's.

"Exit" ist so gut wie immer sauberer, als aus einer verschachtelten Schleife mit Hilfvariablen à la "AbortedFlag" herauszutorkeln.

"Vermeidbar" ist es natürlich immer, aber das sind Schleifen auch: Wozu gibt es schließlich (Rechts-)Rekursion :stupid:

Was ist hier wohl übersichtlicher?

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;
...
//
...
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;

Allerdings würde ich das "FileExists"-Beispiel auch so wie Stevie codieren.

[omata]

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.

[Aphton]

Zitat:

Zitat von Stevie (Beitrag 1097860)

Zitat:

Zitat von Aphton (Beitrag 1097855)

Zitat:

Zitat von Stevie (Beitrag 1097847)

Mag nur meine Meinung, aber für jedes Exit sollte es einen Schlag in den Nacken geben.
Klar, an manchen Stellen kann man sich in etwas vertrackten Konstrukten einfach aus der Affaire ziehen, aber sauber gecoded ist es zu 99.99% vermeidbar.

Ähm, ja, ich hab das auch die meiste Zeit gedacht, aber um den Code kürzer zu halten, ist es wirklich sinnvoll, hier und da mal Exit zu verwenden.
Ein Beispiel:

Delphi-Quellcode:

// mit Exit
begin
  if not FileExists(Filename) then Exit;
  LoadFile();
  ProcessFile();
  DoSomethingElseWithFile();
end;

// ohne Exit
begin
  if FileExists(Filename) then
  begin // extra Zeile
// + Verschachtelung
    LoadFile();
    ProcessFile();
    DoSomethingElseWithFile();    
  end; // extra Zeile

ROFL, hast du mal bei uns gearbeitet? Jedesmal, wenn ich solchen Code in alten Units sehe, ändere ich das sofort. :wall:
Ernsthaft - um 2 Codezeilen zu sparen? Worin leidet denn beim 2. die Lesbarkeit?
Stell dir vor, man baut mal sowas wie Logging ein:

Delphi-Quellcode:

begin
  Logger.EnterMethod('LoadFile');
  if not FileExists(Filename) then Exit;
  LoadFile();
  ProcessFile();
  DoSomethingElseWithFile();
  Logger.LeaveMethod('LoadFile');
end;

begin
  Logger.EnterMethod('LoadFile');
  if FileExists(Filename) then
  begin
    LoadFile();
    ProcessFile();
    DoSomethingElseWithFile();    
  end; 
  Logger.LeaveMethod('LoadFile');
end;

Ah, dann kommt bestimmt die Frage, wie man mit trotz Exit noch bestimmten Code ausführen kann... Merkste was?

Ja klar ist mir das bewusst. In diesem Fall ginge es nicht.
Deshalb meinte ich "hier und da".

Aber es gibt Fälle, in denen es andersherum viel leserlicher und besser ist, so wie von Zacherl angesprochen.

Zumindest habe ich so das Gefühl.

Und noch etwas:

Zitat:

"Ernsthaft - um 2 Codezeilen zu sparen?"

Wenn man mehrere Bedingungen hat, sagen wir mal 20, und jede voneinander abhäng ist - dh. alle Bedingungen erfüllt werden müssen, um eine Ebene tiefer gehen zu können, eignet sich hier meines Erachtens nach nur Exit!
Sonst hast du 2*20 Extra Zeilen und ganz zu Geschweigen von der ganzen Einrückung!

Edit:

Zitat:

Zitat von FredlFesl

Allerdings würde ich das "FileExists"-Beispiel auch so wie Stevie codieren.

Ach herjee, das war ja nur aus den Ärmeln geschüttelt. Es ging dabei nicht um den Inhalt, sondern ums Prinzip :P

[Daniel]

Es gibt keinen Anlass, sich im Ton zu vergreifen - erst recht nicht in der Diskussion, ob man ein Sprachkonstrukt nun verwenden solle oder nicht. Wer das dennoch tut, hat sich hier definitiv zum letzten Mal im Ton vergriffen, meine Güte nochmal. Es ist /NUR/ ein Sprachkonstrukt, vergesst das bitte nicht.

[Satty67]

Normalerweise prüft man die Rahmenbedingungen ja bevor man einen Process startet

Delphi-Quellcode:

begin
  if FileExists(Filename) then
    ProcessFile(Filename)
  else
    ShowMessage('File not exists');
end;

function ProcessFile(Filename);
begin
  bla...
end;

Was ich meine ist, das man ein Exit eigentlich leicht dadurch verhindert, dass man vorm Aufruf einer Function die Rahmenbedingungen prüft. Wenn dann bei Processing ein Fehler auftritt ist eine Exception auch ganz angemessen geantwortet. Einfach ein Exit am Function-Eingang ist ja für den Aufrufer nicht von erfolgreichem Aufruf zu unterscheiden.

Der andere Fall, ein Exit einzusetzten um Aufgabenblöcke zu überspringen, entspricht einem Goto Ende:. Mehr braucht man ja nicht zu schreiben, ausser das sowas auch durch splitten der Aufgaben pro Funktion meist eleganter gelöst wird.

[Stevie]

Zitat:

Zitat von Aphton (Beitrag 1097868)

Wenn man mehrere Bedingungen hat, sagen wir mal 20, und jede voneinander abhäng ist - dh. alle Bedingungen erfüllt werden müssen, um eine Ebene tiefer gehen zu können, eignet sich hier meines Erachtens nach nur Exit!
Sonst hast du 2*20 Extra Zeilen und ganz zu Geschweigen von der ganzen Einrückung!

Imho hast du in dem Fall ganz andere Probleme ;)

Zitat:

Zitat von Satty67 (Beitrag 1097871)

Wenn dann bei Processing ein Fehler auftritt ist eine Exception auch ganz angemessen geantwortet. Einfach ein Exit am Function-Eingang ist ja für den Aufrufer nicht von erfolreichem Aufruf zu unterscheiden.

Was ich meine ist, das man ein Exit eigentlich leicht dadurch verhindert, dass man vorm Aufruf einer Function die Rahmenbedingungen prüft.

Der andere Fall, ein Exit einzusetzten um Aufgabenblöcke zu überspringen, entspricht einem Goto Ende:. Mehr braucht man ja nicht zu schreiben, ausser das sowas auch durch splitten der Aufgabe/Funktion meist eleganter gelöst wird.

Danke.

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

[Aphton]

Ok, wie es nun aussieht, fällt das in die Kategorie "Geschmackssache".
Denn beides hat ihre Vorteile und Nachteile!
Es gibt Fälle, in denen das eine praktischer ist, das andere weniger.
Fundamentalisten werden das nun verweigern, aber so ist das nunmal!
*Keks_mampf

Edit:

Zitat:

Imho hast du in dem Fall ganz andere Probleme

Jupp, da hast du recht! Aber wenn man mal Quick & Dirty auf saubere Art und Weise programmieren will, ist das geeignet