Verständnisfrage zu Exit

[stahli]

Zitat:

Zitat von DasWolf (Beitrag 1475219)

Nein, Nein, Nein und nochmal Nein. Das Result wird nicht am Anfang belegt.

Die Zuweisung am Anfang zu erzwingen ist genau so Unsinn wie das zu verweigern.
Es kommt doch immer auf den Einzelfall an. Darüber hinaus spielen dann auch noch persönliche Vorlieben oder Vorgaben in einer Firma hinein.

Darüber zu streiten macht keinen Sinn.

[DasWolf]

Zitat:

Zitat von Medium (Beitrag 1475220)

Warum das denn?

Alt, aber da halte ich mich immer noch dran: https://www.delphipraxis.net/85402-post.html#93878

[Uwe Raabe]

Zitat:

Zitat von DasWolf (Beitrag 1475223)

Alt, aber da halte ich mich immer noch dran: https://www.delphipraxis.net/85402-post.html#93878

Ich denke, da geht es eher darum das Result als lokale Variable zu missbrauchen. Das hat aber eher was mit Performance zu tun als mit gutem oder schlechtem Programmierstil.

[Benmik]

Zitat:

Zitat von DasWolf (Beitrag 1475219)

Nein, Nein, Nein und nochmal Nein. Das Result wird nicht am Anfang belegt.

Das ist es, was mich so ganz allgemein stört: Warum gibt es im Programmiererclub mehr Dogmen als in der katholischen Kirche, und auch mehr Inquisitoren? Und warum sind die angeführten Gründe für diese Dogmen oft so wie der Beweis der Jungfräulichkeit Mariae? Wie bei Maria spricht viel mehr für die umgekehrte Ansicht.

[Rollo62]

Zitat:

Zitat von Benmik (Beitrag 1475235)

Warum gibt es im Programmiererclub mehr Dogmen als in der katholischen Kirche

Gibts doch gar nicht: Ich mach was mir gefällt

Tralla li tralla la, tralla hopsassa :stupid:

[Rollo62]

Zitat:

Zitat von Benmik (Beitrag 1475235)

Warum gibt es im Programmiererclub mehr Dogmen als in der katholischen Kirche,

Aber Du hast sicher Recht, ein bischen lockerer könnten die Puristen schon werden.

Result als lokale Variable:
- Ja, da wo es Sinn macht

Exit als Vorbedingung
- Ja, wenn es zig Verschachtelungen vermeidet

...
...
...

Habe ich theroretische Philosophieprobleme damit ?
Nein, wenn ich weiss was ich da tue.


Ausserdem versuche ich es möglichst gut visuell zu dokumentieren:

Delphi-Quellcode:

begin
   if VorbedingungFails then
   begin
      Exit; //<== Leave here ==============================================
   end;

  ...
end;

[Stevie]

Zu "Exit ist genauso böse wie goto" - sehe ich nicht so - Exit hat ein unverrückbares Ziel: das Ende der Routine, wohingegen zu einem goto immer ein label gehört, was sonstwo sein kann.

Zu "Result erst so spät wie möglich setzen" - ja, das verhindert, dass der Compiler den Wert für eine Weile merken und zwischenspeichern muss, entweder auf dem Stack oder er blockiert ein Register, was dann woanders fehlt. Aber wenn man bei dieser Argumentation ist, dann muss man noch ganz viele andere Dinge beachten und sich fragen, ob man das dann macht, wenn man genau weiß warum oder einfach nur "cargo cult" folgt.

Zu "Exit benutzen oder nicht" - teilweise Geschmackssache, ich nutze gern ein Exit aus einer "suche mir ein Element"-Schleife und handhabe den "kein Fund"-Fall einfach nach der Schleife. Oder ich verabschiede mich nach einigen anfänglichen negativ formulierten Überprüfungen gleich mit einem Exit, so dass ich den ganzen eigentlichen Code nicht unterhalb der positiv formulierten Bedingung in einem Block habe (sofern nicht absolut optimiert, denn da gelten wieder andere Regeln - Stichwort branchless programming bzw common path ohne conditional jump taken).

Eine Sache noch zu Exit oder nicht - die Benutzung von Exit kann durchaus dafür sorgen, dass der Compiler auch tatsächlich an dieser Stelle ein ret einbaut wohingegen der Fall mit einem else... ein jmp an das end der Routine erfolgt.

[Andreas13]

Hallo,
auch ich benutze Exit bei numerischen Berechnungen recht oft, häufig in folgender beispielhafter Weise:

Delphi-Quellcode:

Function Komplizierte_Berechnung(CONST a, b, c: Extended; 
            CONST X_Vektor, Y_Vektor, Z_Vektor: TExtended_Array; 
                                  VAR A_Matrix: TExtended_Matrix; 
                                   VAR f, g, h: Extended): Integer;
VAR
  Diverse dynamische Strukturen;

Begin
  Dynamische Strukturen initialisieren;
  . . .
  Try
    IF NOT Check_1(...) Then
    Begin
      Exit(ErrorCode_1);
    End;


    IF NOT Check_2(...) Then
    Begin
      Exit(ErrorCode_2);
    End;
    . . . 

    IF Bedingung_1 Then
    Begin
      Berechnungen_1;
      Exit(ErrorCode_3);
    End;

    IF Bedingung_2 Then
    Begin
      Berechnungen_2;
      Exit(ErrorCode_4);
    End;

    . . . 

  Finally
    Rückgabeparameter schreiben;
    Dynamische Strukturen freigeben;
  End;
End;

Ich habe damit gute Erfahrungen gemacht.
Gruß, Andreas

[Medium]

Zitat:

Zitat von Stevie (Beitrag 1475247)

Zu "Exit ist genauso böse wie goto" - sehe ich nicht so - Exit hat ein unverrückbares Ziel: das Ende der Routine, wohingegen zu einem goto immer ein label gehört, was sonstwo sein kann.

Zu "Result erst so spät wie möglich setzen" - ja, das verhindert, dass der Compiler den Wert für eine Weile merken und zwischenspeichern muss, entweder auf dem Stack oder er blockiert ein Register, was dann woanders fehlt. Aber wenn man bei dieser Argumentation ist, dann muss man noch ganz viele andere Dinge beachten und sich fragen, ob man das dann macht, wenn man genau weiß warum oder einfach nur "cargo cult" folgt.

Zu "Exit benutzen oder nicht" - teilweise Geschmackssache, ich nutze gern ein Exit aus einer "suche mir ein Element"-Schleife und handhabe den "kein Fund"-Fall einfach nach der Schleife. Oder ich verabschiede mich nach einigen anfänglichen negativ formulierten Überprüfungen gleich mit einem Exit, so dass ich den ganzen eigentlichen Code nicht unterhalb der positiv formulierten Bedingung in einem Block habe (sofern nicht absolut optimiert, denn da gelten wieder andere Regeln - Stichwort branchless programming bzw common path ohne conditional jump taken).

Eine Sache noch zu Exit oder nicht - die Benutzung von Exit kann durchaus dafür sorgen, dass der Compiler auch tatsächlich an dieser Stelle ein ret einbaut wohingegen der Fall mit einem else... ein jmp an das end der Routine erfolgt.

Hier kann ich in allen Punkten volle Zustimmung geben und Fanboy-Flaggen wedeln. *wedel*

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1475229)

Ich denke, da geht es eher darum das Result als lokale Variable zu missbrauchen. Das hat aber eher was mit Performance zu tun als mit gutem oder schlechtem Programmierstil.

Ich sehe das sogar eher andersrum.

Empfinde es schlecht hässlich, wenn man sinnlos eine weitere Variable benutzt, anstatt direkt Result.

Und von der Preformance her ist das kein Unterschied.
Es kann sogar sein, dass die zusätzliche Variable mehr speicher benötgt, wenn es für den Compiler nicht möglich ist, die Resultvariable (deren Speicherplatz) erst ab der Stelle der Zuweisung zu reservieren.


Es gibt aber Einwas, wo man das als Nachteil betrachten könnte.
Denn z.B. ein Result als Interface oder String, wird vom Compiler als VAR-Parameter behandelt.
Kommt es dann zu einer Exception, dann würde die äußere Variable (da wo das Result der Funktion zugewiesen werden sollte) bereits verändert sein, was man so nicht direkt erwarten würde.

Delphi-Quellcode:

function MyFunc: string;
begin
  Result := '2';
  raise Exception.Create('');
end;

procedure Test;
var
  X: string;
begin
  X := '1';
  try
    X := MyFunc;
  except
    ShowMessage(X);
  end;
end;

Das selbe Beispiel mit Integer als Variable/Result, da bleibt es "1", da an "X" ja noch nchts zugewiesen wurde, weil es "vorher" abgeraucht ist.

Für mich sind nach einer Exception Results von jeglichen Funktionen sowieso als "ungültig" anzusehen, somit gibt es IMHO damit eigentlich auch keine Probleme.