Procedure in Procedure

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

[OlafSt]

Ist es noch immer so, das lokale Prozeduren einen heftigen Aufruf-Penalty innehaben ? Ich meine mich zu erinnern, das dem so war und ich deswegen diese Konstrukte meide wie die Pest...

Ansonsten habe ich schon genug Beispiele gesehen, in denen lokale Prozeduren ein Alptraum an Unübersichtlichkeit produziert haben (Prozedur, 40k Zeilen lang (an sich schon ein Problem), darin eingebaut 15 lokale Prozeduren im 100-Zeilen-Bereich) - schier undurchdringlich, das Dickicht )

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

[bernau]

Zitat von himitsu:

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

Wer sagt, daß ich das nicht so gemacht hätte

Aber auch das ist Ansichtssache. XmlParser und TrvDoc sind anscheinend in TFrmMain deklariert. Warum sollte ich keine private Methode zur Form schreiben, die direkt auf diese deklarationen zugreift?

[Popov]

Prozeduren/Functionen in Prozeduren sind an sich eine feine Sache. Ob der obere Code nicht auch ohne eine ausgekommen wäre, ist eine Ansichtssache, ich hätte vermutlich es auch so gemacht. Im Grunde nutze ich diese Möglichkeit sogar sehr oft. Der Grund ist simpel - zuerst wie gesagt, man kann es auch über eine Prozedur lösen, aber wenn man sich die zweite Prozedur anguckt, ist sie allgemein gehalten, hat also keinen direkten Bezug zu TFrmMain. Allgemeine Prozeduren kann man immer wieder gebrauchen, ob im gleichen Projekt oder in später in anderen. Hat man alles in einer Prozedur, ist die Prozedur mit den Bezeichnungen andere Komponenten "verunreinigt". Spätere Nutzung ist somit schwieriger, man muss die Prozedur denn erst "bereinigen". Ist sie allgemein gehalten, kann man sie immer wieder nutzen.

Hat man eine allgemeine Prozedur, kann man sie auch direkt in die Unit packen. Wenn aber nur die eine einzige Prozedur sie nutzt, dann packe ich sie auch in die Prozedur. Das erhöht die Lesbarkeit, ich weiß, dass nur die Prozedur die andere Prozedur nutzt.

Womit die erste Aussage im Grunde stimmt: sowas erhöht die Übersichtlichkeit.

[Dejan Vu]

Aber eigentlich ist es schon unübersichtlich, die Logik in der Form unterzubringen. Hätte man dafür eine eigene Klasse, wäre dort die private Methode sehr gut aufgehoben. So machen wir das jedenfalls.

[himitsu]

Bei kleines Funktionen/Proceduren nutze ich sowas manchmal, um "klarzustellen", daß diese eingebette Funktionen/Proceduren ausschließlich zur Übergeordneten Funktionen/Proceduren/Methode gehört.
[edit] Jupp, im Prinzip ist das so eine private Methode der übergeordneten Prozedur.

Und der einzige "Vorteil" ist, daß man direkten Zugriff auf lokale Variablen der übergeordneten Methode besitzt. (auf Die, welche davor deklariert sind)

[stahli]

Ich nutze so etwas auch öfter wegen der (für mich) besseren Übersichtlichkeit:

Delphi-Quellcode:

procedure DoSommething;
 procedure DoA;
 ...
 procedure DoB;
 ...
 procedure DoC;
 ...
begin
 DoA;
 DoB;
 DoC;
end;

Benötigte Parameter übergebe ich meist beim Prozedur-Aufruf (so dass ich die Unterprozeduren generell auch auslagern könnte).

Wie schon geschrieben, letztlich ist das Geschmackssache und ich entscheide das auch von Fall zu Fall unterschiedlich.

[himitsu]

Wobei inzwischen (seit über 5 Jahren) auch sowas ginge:

Delphi-Quellcode:

procedure DoSommething;
begin
  {$REGION 'DoA'}
  ...
  {$ENDREGION}
  {$REGION 'DoB'}
  ...
  {$ENDREGION}
  {$REGION 'DoC'}
  ...
  {$ENDREGION}
end;

Regionen lassen sich ja zusammenklappen.