Frage zu proceduren innerhalb anderer proceduren

[Gebhard]

Hallo,

beim lesen verschiedener Beispiele sehe ich manchmal, dass sich innerhalb von proceduren andere proceduren befinden Beispiel
beliebiges Beispiel aus diem Forum. In diesem Beispiel befindet sich innerhalb der Procedure "SetClipboardText" die Procedure "SetBuffer".
Habe ich hier etwas falsch gelesen und wenn nicht, welchen Sinn macht diese Vorgehensweise?

Vielen Dank für Eure Antwort

Gruß

Gebhard

[Willmar.Heinrich]

In dem zitierten Beispiel sehe ich es im Sinne einer besseren Lesbarkeit der Quellcodes.

Gruß, Willmar

[DelphiBandit]

Zitat von Gebhard:

Habe ich hier etwas falsch gelesen und wenn nicht, welchen Sinn macht diese Vorgehensweise?

Nein, das hast Du völlig richtig verstanden. Der obere Block ist eine lokale Prozedur, welcher nur im Gültigkeitsbereich der Hauptprozedur bekannt ist. Und auch nur dort aufgerufen werden kann.

Eingesetzt wird dieses Verfahren, wie auch schon Willmar anmerkte, hauptsächlich um die Lesbarkeit des Quellcodes zu erhöhen. Viele kleine lokale Prozeduren oder Funktionen, von denen jede nur einen Teil der Aufgabe erledigt und innerhalb der Hauptprozedur eine Aneinanderreihung derselben. Die Unterfunktionen/-prozeduren sollten dabei aber sehr speziell sein und nur an dieser Stelle Verwendung finden können. Sobald man Teile mehrfach verwenden kann, sollten diese Teil z.B. des Private-Teils der Klasse sein.

In dem von Dir angeführten Beispiel erschliesst sich wegen dem einzeiligen Aufruf der Unterprozedur der Sinn allerdings nur sehr begrenzt

[Medium]

Der Spaß nennt sich "nested procedure" (können aber genau so gut functions sein), und ist eigentlich eher als Relikt zu betrachten, auch wenn der eine oder andere durchaus Argumente für die Benutzung im Einzelfall anbringen dürfte.
Letztlich geht es nur darum, Code der in der Mutter-Funktion/Prozedur sonst mehrfach geschrieben werden müsste, auszulagern. Diese nested procedures sind ausserhalb der Mutter-Funktion nicht sichtbar, und sie können zudem auf die lokalen Variablen der Mutter-Funktion zugreifen - was auch gleich schon ein Argument gegen ihre Verwendung ist, da dies extrem unübersichtlich/-erwartet sein kann.

Heutzutage, im Zeitalter von Klassen und Co, ist sowas eher über ganz normale private Methoden vorzuziehen. Dann können zwar andere Methoden der Klasse diese auch sehen, aber das tut keinem Weh, und man spart sich ggf. Umbauten wenn man diese Unterfunktion doch noch an anderer Stelle in der Klasse brauchen könnte.

Es gibt halt so eine halbe Hand voll Spezialfälle wo diese Dinger echt komfortsteigernd sind, aber im Großen und ganzen mindern sie eher die Lesbarkeit im Vergleich zu der Alternative.

[himitsu]

Zitat von Medium:

"nested procedure"

Also für kleine Dinge und vorallem bei Prozeduren/Funktionen, welche nicht in Klassen verpackt sind, nutze ich auch gern sowas.
Denn wie gesagt, kann man so vorallem leichter erkennen, wozu sie gehören, ohne gleich alles mit Kommentaren vollstopfen zu müssen.

Und gerade der Vorteil auf Parameter und lokale Variablen zugreifen zu können ist ein großer Vorteil.
Gut, hier muß man aufpassen und darum werden (bei mir) solche Variablen vor den "nested procedures" deklariert und die Restlichen danach.
Immerhin kann man so auch einiges Einsparen und übersichtlicher machen, wenn man dieses mit Bedacht einsetzt.

PS: Wie hießen nochmal diese "neumodischen" Funktionen, welche man mitten im QuellCode deklarieren kann?
irgendwie so

Delphi-Quellcode:

SL.Sort(function(a, b: irgendwas)
  begin  Result := Vergleiche(a, b);  end);

Und jetzt erkläre mir mal jemand, warum dann diese extremen "nested procedures" so toll sind
und was an den einfachen "nested procedures" soooooo schlimm sei?

[Gebhard]

Hallo,

vielen Dank für Eure Antworten.

Tschüss und schöne Ostern

Gebhard

[Medium]

Zitat von himitsu:

[...] Prozeduren/Funktionen, welche nicht in Klassen verpackt sind

Sind, zumindest wenn man sich in Objekt orientierter Umgebung bewegt, von vorn herein schon als Designfehler anzusehen.

Zitat:

Denn wie gesagt, kann man so vorallem leichter erkennen, wozu sie gehören, ohne gleich alles mit Kommentaren vollstopfen zu müssen.

Ich schreib meine Helferlein deswegen ganz gern direkt vor oder hinter die "Benutzer-Methoden", und moderne IDEs machen's einem ohnehin sehr leicht vom Aufruf zur Implementierung zu hüpfen, ohne auch nur eine Zeile scrollen zu müssen.

Zitat:

Und gerade der Vorteil auf Parameter und lokale Variablen zugreifen zu können ist ein großer Vorteil.
Gut, hier muß man aufpassen und darum werden (bei mir) solche Variablen vor den "nested procedures" deklariert und die Restlichen danach.

Und wenn dann die nested Procedure länger als der sichtbare Ausschnitt wird, ist die Verwirrung perfekt.

Zitat:

Immerhin kann man so auch einiges Einsparen und übersichtlicher machen, wenn man dieses mit Bedacht einsetzt.

Einsparen, ja, aber es ist dabei im Potential gleichwertig mit normalen Methoden. Übersichtlich: Nur wenn man 1-2 Drei- bis Vierzeiler so kapselt - und dabei nicht wild in übergeordneten Variablen doktort. Das ist in Zeiten von automatischem Inlining nicht einmal mehr ein Performanceargument, und im Grunde kann man sogar eine sehr ähnliche Argumentation dagegen führen, die man gegen globale Variablen ansetzt.

Zitat:

PS: Wie hießen nochmal diese "neumodischen" Funktionen, welche man mitten im QuellCode deklarieren kann?

Anonyme Methoden. Sobald man diese für mehr als Einzeiler einsetzt, gehört man genau so an die Wand gestellt

Zitat:

Und jetzt erkläre mir mal jemand, warum dann diese extremen "nested procedures" so toll sind
und was an den einfachen "nested procedures" soooooo schlimm sei?

Teil 1 sollte beantwortet sein, Teil 2 eigentlich auch. Aber weil du es bist: Weil es in 99,9% der Fälle zu zusätzlicher Verwirrung führt. Insbesondere wenn es mal nicht der eigene Code ist, oder man ihn ein paar Jährchen nicht mehr im Sinn hatte. Und joa, ich spreche dabei aus leidvoller Erfahrung

[himitsu]

Zitat von Medium:

Und wenn dann die nested Procedure länger als der sichtbare Ausschnitt wird, ist die Verwirrung perfekt.

Dafür hab ich meine Codeformatierung:

"normale" Prozeduren, Funtionen und Methoden liegen auf einer oberen Ebene (haben also 2 Leerzeichen davor)

die "nested" Proceduren liegen eine Ebene tiefer ... unterhalb der Elern-Prozedur (haben also 4 Leerzeichen davor und das nahfolgende BEGIN auf gleicher Höhe wäre dann der Beginn der Elternprozedur)


Aber OK, längere Prozeduren lagere ich inzwischen auch immer öfters aus.