Hallo zusammen,

ich habe in einem Tutorial etwas in der Art entdeckt:

markieren

Delphi-Quellcode:

procedure TTestKlasse.nurEinTest();
  function test(): integer;
  begin
    result := 5;
  end;
begin
  test;
end;

Dieses Einbetten einer Routine in eine andere sieht für mich ziemlich krank aus...
Ist das normal?!? Nutzt das jemand? Macht es Sinn? (damit meine ich nicht diese unsinnige Prozedur )

Würde mich mal interessieren...

Würd mich auch mal interessieren. Krank sieht das zwar nicht aus, aber unübersichtilich schon!

Ich nehm mal an, dass die Funktion nur auf diese eine Prozedur anwendbar ist oder?

Wenn man vor und hinter der "nested" Prozedure eine Leerzeile einfügt, dann IST das ein sauberer Programmierstil.
Das ist absolut nicht krank, sondern sogar eine sehr gute Methode um prozedurale Techniken stärker zu modularisieren. Überführt man das NICHT-kranke PROGRAM/LIBRARY Konzept auf das NICHT-kranke UNIT Konzept, auf das NICHT-kranke INTERFACE/IMPLEMENTATION Konzept dann ist der nächste logische Modularisierungs-Schritt der Schritt zum NICHT-kranken PROCEDURE/nested Procedure Konzept.

Gruß Hagen

Das ist echtes und sinnvolles Pascal.
Indem man Codeteile in sinnvolle Teilfunktionen zerlegt, bekommt man flexibleren und besser wartbaren Code.
Je kleiner die Funktion desto leichter laesst sich ihre Korrektheit ueberpruefen.
Eine sinnvolle Zerlegung vermeidet Copy & Paste-Sourcen, die eine haeufige Quelle von Fehlern sind.
Indem man sinnvoll strukturiert kann man auch Fehlern im Ansatz leichter auf die Spur kommen.

Wird von mir genutzt.

Sinn: Eine größere Aufgabe wird in mehrere Blöcke/Einzelfunktionen zerlegt. Diese Allgemein zur Verfügung zu Stellen ist aufgrund der absoluten nur für diese Funktion Verwendbarkeit nicht gegeben.

Hallo!

Ich mache das so wenn ich Schleifen innerhalb einer Funktion oder Prozedur mehrfach benötige und diese Definitiv nicht außerhalb brauche.

Wenn man sich an eine "anständige" Einrückung hält, finde ich das vollkommen OK.

Stevie

Das nutze ich regelmaessig bis in eine Ebene von ca. 4 Schachtelungen.
Ist einfach praktisch, um Methoden ihre eigenen kleinen Hilfsfunktionen mitzugeben, die verfuegbar bleiben, wenn die Methoden im Source umhergeschoben werden. Ausserdem unterstuetzt es die Kapselung.

Ist richtig, die eingebettete Funktion (oder Prozedur) ist nur der "Mutter"-Funktion oder Prozedur bekannt. Ich habe das z.B. mal in meinem Parser genutzt. Ein praktischer Nutzen: Die "Kind"-Funktionen kennen die Variablen der "Mutter"-Funktion - und die sind damit also quasi in dieser "Mutter"-Funktion Semi-Global. Man muss also nicht so viel Parameterübergabe machen, wenn klar ist, dass die eingebetteten Funktionen nicht auch einzeln verwendet werden sollen/müssen.

Sieht nicht wirklich hübsch aus, kann aber sehr praktisch sein, und ist meiner Meinung nach auch in Sachen "Stil" völlig okay.

gruss,
dizzy

Hinsichtlich des Codestils bevorzuge ich:
- Weglassen der leeren runden Klammern
- Integer statt integer
- Result statt result
- NurEinTest statt nurEinTest
- Test statt test
- eine Leerzeile vor und hinter der lokalen Funktion

Zitat von BKempf:

Das nutze ich regelmaessig bis in eine Ebene von ca. 4 Schachtelungen.

Das geht an die Grenze der Lesbarkeit. Das sind bereits 8 Zeichen Einrueckung.
Nicht viele Programmierer koennen dieser Tiefe folgen, besonders wenn Bezug auf globalere Variablen genommen wird.
Der Bezug auf globalere Variablen sollte vermieden werden. Parameter sind verstaendlicher und erlauben
tief verschachtelte Funktionen ohne Aenderung nach aussen in der Verschachteung zu ziehen.

Refactoring aka "alles umschreiben" ist eine haeufige Taetigkeit. Die Source sollte daher leicht zu aendern sein.