Ist das sauberer Programmierstil?!

[dizzy]

Zitat:

Zitat von Robert Marquardt

Parameter sind verstaendlicher und erlauben
tief verschachtelte Funktionen ohne Aenderung nach aussen in der verschachteung zu ziehen.

Sie sind aber letztlich auch langsamer, oder?

[Robert Marquardt]

Zitat:

Zitat von dizzy

Sie sind aber letztlich auch langsamer, oder?

Ja, aber man schreibt den Code nicht gleich auf Performance.
Erst muss er korrekt laufen, dann kann man ihn beschleunigen.
Erst sollte man die algorithmischen Moeglichkeiten zu Ende optimieren,
bevor man auf Instruktionsebene optimiert.

[dizzy]

Gelesen und für gut befunden :)

[Robert Marquardt]

Ja im :warn:-Modus bin ich gut :tongue:

[Phoenix]

Das ganze hat noch einen Vorteil:

Sollte die nested Procedure doch irgendwann einmal woanders benötigt werden, so kann diese recht einfach aus der Funktion/Prozedur entfernt und sozusagen Standalone eingesetzt werden.

Das lässt sich hinterher leichter warten.

[negaH]

Zitat:

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.

Irrelevant. Der Sinn ist es doch diese Teil-Aufgaben selber als "Black-Boxes" zu verifizieren. Somit würde sich sogar eine 16 fach nested Funktion immer noch lohnen falls man ihre Funktionalität aus sich selber heraus verifizieren kann. Statt also eine Monster Funktion im Gesammten zu verifizieren, würde man mit nested Funktionen Stück für Stück verifizieren. Sobald eine solche nested Funktion verifiziert wurde, kann man sie aus dem Kopf streichen und einfach überlesen.
Somit erhöht die Modularisierung, egal ob nested Funktion oder Objectmethoden oder Units oder externe DLL's, immer auch die Wartbarkeit und Lesbarkeit. Der EINZIGSTE relevante Unterschied zwischen nested Funktionen und anderen Methoden der Modularisierung besteht in ihere Gültigkeit=Scope. Nun nested Funktionen sind globale für die Übergeordneten Scopes, aber Lokale innerhalb des übergeordenten Scopes. Sie können also auf anderer Modularisierungsebene, zB. Objecten, Units, Program, Library nicht merhfach benutzt werden.
Somit ist auch die logische Frage geklärt WANN man zu nested Funktionen greifen sollte.

Das Konzept der nested Funktionen ist also absolut sauberer Programmierstil.

@Performance:
Da der Delphi Optimierer immer lokal zu einer Procedure optimieren kann, also NICHT Procedure-übergreifend, sind durch die Vereinfachungen komplexer Proceduren mit Hilfe von nested Prozeduren sogar erhebliche Performance-Steigerungen zu erwarten. Statt also EINE Prozedure mit 100 zu optimierenden Variablen zu optimieren kann der Compiler bei nested Funktionen viel kleine und voneinander unabhänig abgeschlossenen Optimierungen vornehmen. Dadurch ist eine höher Performance des erzeugten Gesamtcodes zu erwarten.
WICHTIG! ist dabei nur eines, die nested Funktionen sollte NICHT allzuofft auf Variablen der übergeordneten Funktion zugreifen. Statt also nested Funktionen ohne Parameter zu benutzen, ist es besser eben auch den nested Funktion so wie mit jeder anderen Procedure/Methode usw. die releaventen Daten als Paramter zu übergeben. Benutzt eine nested Funktion KEINERLEI Zugriffe auf übergeordete Lokale Stack Variablen, so kann der Optimieren einen zusätzlichen Stackframe wegoptimieren. Dadurch wird nochmals die Gesamtperformance gesteigert.


Gruß Hagen

[dizzy]

[OT] Ich find es immer wieder interessant, dass die wirklich interessanten kleinen netten Infos meist so am Rande mitten in einem Thread eingebettet kommen :mrgreen: [/OT]

[neolithos]

So sieht der Zugriff aus

Bsp

Delphi-Quellcode:

procedure FuncTop(a : integer);
var b : Integer;
    s : single;

  procedure FuncBetween(c : Integer);
  var d : Integer;
    procedure FuncBottom(e : Integer);
    var f : Integer;
    begin
      f := 6;
      Print(a, b, c, d, e, f);
    end;
  begin
    d := 4;
    FuncBottom(5);
  end;
begin
  b := 2;
  s := 1.3 / b;
  if s < b then
     FuncBetween(3);
end;

Zugriff auf b in FuncBottom

Code:

mov eax, [ebp+8] // Hole Zeiger auf Stackframe von FuncBetween
mov eax, [eax+8] // Hole Zeiger auf Stackframe von FuncTop
mov eax, [eax-4] // Hole Inhalt der Variable b

Deswege sollte den Zugriff auf häufig genutzte Variable via Parameter realisieren -> const var. Stellen eine wesentlich schnellere Alternative dar.

[Vitus]

Ich halte es einfach für fraglich ob dem OOP Konzept damit genüge getan wird...

Thema Copy & Paste Code: Das ist doch eigentlich gerade der Nachteil dieser "nested" Rutine!
Wenn ich nun nämlich feststelle dass diese genestete Funktion auch an anderen Stellen prima einsetzbar ist, dann fängt das copy & gepaste doch an!!

Ich würde in so einem Fall eher eine eigene private Funktion innerhalb der Klasse schreiben. Die kann ich innerhalb der Klasse auch innerhalb von anderen Prozeduren und Funktionen nutzen.

Ich sage nichts gegen die zerstückelung des Codes in Möglichst kleine Einheiten! Ich glaube anders kann man größere Projekte gar nicht bewältigen. Aber das da oben halte ich für ungünstig...


achja - um Einrückung und Groß-Kleinschreibung ging es mir eigentlich gar nicht *g* Das war nur schnell hingetippt - mir ging es wirklich nur um diese Funktion.

[SirThornberry]

Ich verwende das eigentlich nur wenn ich eine procedure oder funktion außerhalb einer klasse hab (bsp.: GetAlphaBlendColor) und darin hab ich dann eine nested-funktion die mir den Geblendeten wert zweier Farbbytes zurückgibt. Die nested-funktion außerhalb zu defnieren würde das ganze viel unübersichtlicher machen weil diese funktion als standalone keinen sinn macht. Wenn man dann irgendwann mal diese unit wieder öffnet und die funktion als standalone darin wäre müsste man erst suchen wofür diese benötigt wird, da sie aber in einer anderen funktion drin ist wird die unit gleich viel übersichtlicher weil nicht haufen einzelnen funktionen darin rumliegen die eventuell als standalone 0 sinn machen