Procedure in Procedure

[bernau]

Übersichtlich ist das Beispiel gar nicht. In dem Besipiel macht es m.E. keinen Sinn. Es macht Sinn, wenn die entsprechende Procedure mehrfach in der umschliessenden Procedure aufgerufen wird.

[bernau]

Ach ja. Sollten in der äusseren Procedure Variablen deklariert sein, kann die innere Procedure darauf zugreifen. Ist im Besispiel aber nicht gegeben.

[vagtler]

Zitat von bernau:

Übersichtlich ist das Beispiel gar nicht. [...]

Das ist Ansichtssache.

[bernau]

Stimmt. Ansichtssache

Aber in dem Fall hätte man die innere Procedure komplett auslagern können, da ja nicht auf Variablen der äusseren Procedure zurückgegriffen wird.

[EWeiss]

Zitat von bernau:

Stimmt. Ansichtssache

Aber in dem Fall hätte man die innere Procedure komplett auslagern können, da ja nicht auf Variablen der äusseren Procedure zurückgegriffen wird.

Welchen sinn macht das ?
Wenn diese Procedure im gesamten Code nur einmal verwendet wird.
Irgendwie unlogisch oder?

gruss

[bernau]

Zitat von EWeiss:

Zitat von bernau:

Stimmt. Ansichtssache

Aber in dem Fall hätte man die innere Procedure komplett auslagern können, da ja nicht auf Variablen der äusseren Procedure zurückgegriffen wird.

Welchen sinn macht das ?
Wenn diese Procedure im gesamten Code nur einmal verwendet wird.
Irgendwie unlogisch oder?

gruss

Wie ich oben schon geschrieben hatte, finde ich es unübersichtlich diesen Code als Nested Procedure zu definieren. Daß dies eine Ansichtssache ist, stimme ich zu.

Aber Unlogisch finde ich es nicht, die Funktion komplett auszulagern und nicht Nested zu verwenden. Auch wenn diese nur einmal verwendet wird. Wer sagt, daß dieser Codeabschnitt nicht doch noch irgendwann ein zweites mal mal verwednet werden soll?

[Nersgatt]

Ich finde immer, bei normale privaten Methoden ist klarer, welchen Scope die lokalen Variablen haben.
Bei Nested procedures hab ich da immer so meine Probleme. Klar, technisch ist ganz klar, welchen Scope die Variablen haben. Es lässt sich aber etwas mühsam aus dem Quelltext rauslesen.
Das ist mein Hauptgrund, eher eine private Methode als eine nested procedure zu verwenden. Auch wenn sie nur 1x aufgerufen wird.

[Nersgatt]

Das mit der Übersichtlichkeit ist natürlich immer subjektiv.

Man hätte sich hier auch den Parameter sparen können, da offensichtlich immer NIL übergeben wird. Es sieht so aus, als wäre die innere Procedure ein Relikt aus Zeiten, wo der Aufruf noch öfter (mit verschiedenen Parameterwerten) vorkam.

Trotzdem kann die Aufteilung schon Übersichtlichkeit bringen (wie gesagt, die Funktion des Codeabschnitts ergibt sich hier schon aus dem Namen).
Ich persönlich nutze diese Procedure-in-Procedure-Konstrukte recht selten. Hier in dem Fall hätte ich auch eine private procedure von TfrmMain davon gemacht.

[himitsu]

Eventuell war in der Procedur früher mal ein rekursiver Code, der dann später zu diesem iterativen Code umgebaut wurde?
Und der Einfachheit halber ließ man den Code dann ganz einfach dort.

Zitat von bernau:

Aber in dem Fall hätte man die innere Procedure komplett auslagern können, da ja nicht auf Variablen der äusseren Procedure zurückgegriffen wird.

Auslagern gut und schön, aber dann auch bitte richtig!
Also XmlParser und TrvDoc gehören gefälligst in den Parametern übergeben.

[Dejan Vu]

Variante 1;

Delphi-Quellcode:

Procedure Something();
Begin
  if Foobar>23 then Stuff:=Bar;
  For bar in foo do  begin
  ...
  end;
end;

Variante 2:

Delphi-Quellcode:

Procedure Something();
  Procedure SetStuff();...
  Procedure ProcessAllFoos();...
Begin
  SetStuff();
  ProcessAllFoos();;
end;

Variante 2 *dokumentiert* ohne Kommentar. Prozeduren sind ja nicht nur dazu da, um Redundanz zu vermeiden, sondern sollen die Lösung (also den Code) in Teillösungen unterteilen. Im Idealfall so, das jede Teillösung (aka Prozedur, Methode) nur eine einzige Aufgabe hat (=> Clean Code).

Die Sache mit den lokalen Prozeduren ist ein Überbleibsel aus der Vor-OOP-Zeit. Mittlerweile würde man das eher als private Methode umsetzen.