![]() |
AW: Procedure in Procedure
Zitat:
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? |
AW: Procedure in Procedure
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 ;)) |
AW: Procedure in Procedure
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. |
AW: Procedure in Procedure
Zitat:
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? |
AW: Procedure in Procedure
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. |
AW: Procedure in Procedure
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.
|
AW: Procedure in Procedure
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) |
AW: Procedure in Procedure
Ich nutze so etwas auch öfter wegen der (für mich) besseren Übersichtlichkeit:
Delphi-Quellcode:
Benötigte Parameter übergebe ich meist beim Prozedur-Aufruf (so dass ich die Unterprozeduren generell auch auslagern könnte).
procedure DoSommething;
procedure DoA; ... procedure DoB; ... procedure DoC; ... begin DoA; DoB; DoC; end; Wie schon geschrieben, letztlich ist das Geschmackssache und ich entscheide das auch von Fall zu Fall unterschiedlich. |
AW: Procedure in Procedure
Wobei inzwischen (seit über 5 Jahren) auch sowas ginge:
Delphi-Quellcode:
Regionen lassen sich ja zusammenklappen.
procedure DoSommething;
begin {$REGION 'DoA'} ... {$ENDREGION} {$REGION 'DoB'} ... {$ENDREGION} {$REGION 'DoC'} ... {$ENDREGION} end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz