Ist das sauberer Programmierstil?!

[Vitus]

Mich würde dann mal interessieren ob ihr dann auch sowas zustande bringt:

Delphi-Quellcode:

procedure TTestKlasse.nurEinTest();

  function test(): Integer;

  TTest = Record
    x     : Integer;
    y     : Integer;
  end;

  begin
    machMitDemRecordIrgendwas;
    result := 5;
  end;

begin
  test;
end;

Übrigens interessant zu sehen wieviele Meinungen es zu einem so "unwichtgen" Thema gibt

[negaH]

Zitat:

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

Wer redet hier von Object Orientierter Programmierung ??
Nested Funktionen sind ein reines Hilfsmittel der prozeduralen Programierung, und OOP nutz eine spezielle Form der prozeduralen Programmierung um zusätzlich neue Möglichkeiten zu erreichen.

Zitat:

Thema Copy & Paste Code: Das ist doch eigentlich gerade der Nachteil dieser "nested" Rutine!

Eine Nested Funktion wird erstmal primär IMMER mit deren übergeordneter Funktion zusammen kopiert. Beides, die übergeordnete Funktion UND die nested Funktionen bilden EINE Einheit. Aus konzeptioneller macht es also keinen Sinn die nested Funktion separat zu kopieren, da sie logisch gesehen OHNE die übergeordnete Funktion keinen Sinn macht. Sogesehen macht es gerade beim Copy&Paste sinn mit nested Funktionen zu arbeiten, da man durch das Kopieren des äußersten Scopes die notwendigen nested Funktionen MIT-Kopiert, statt sie zu vergessen.

Zitat:

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!!

Eben exakt in diesem Moment hast du den Sinn der nested Funktionen NICHT verstanden, und die nested Funktion statt der günstigeren normalen Funktion benutzt. Erstmal bestreitet ja keinr hier das man bei Mehrfachbenutzung der gleichen Funktionalität eben KEINE nested Funktion nehmen sollte. Aber gerade für Erstentwicklungen bei denen man NICHT abschätzen kann ob eine hochspezielisierte Funktion tatsächlich mehrmalig benutzt wird, machen nested Funktion Sinn. Denn im späteren Verlauf ist es ein Leichtes aus der nested Funktion eine globale zu machen, OHNE das man am wichtigen Source was ändern müsste.
Somit, verkehrt sich deine Argumentation in das exakte Gegenteil, und alles spricht FÜR nested Funktionen.

Zitat:

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.

Wer sagt denn hier was darüber das man überhaupt mit Objekten arbeitet ?
Wie soll einer eine nested Funktion in ein Objekt als private Methode deklarieren wenn er garkein Objekt dafür hat ?
Davon abgesehen: wenn in einer Objectmethode eine nested Funktion benutzt wird dann hat das eben den Grund die Sichtbarkeit der nested Funktion noch viel stärker einzuschränken als dies mit einer privaten Methode möglich wäre !

Zitat:

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

Worin besteht für dich der Unterschied zwischen kleinen und großen Projekten, in Bezug auf die Regeln der Modularisierung der Sourcen ??

Es gibt da keinen Unterschied in diesem Punkt. Der einzigste Unterschied bestünde in der Anzahl der Module/Schnittstellen und deren Komplexität, ABER NICHT in der Art und Weise wie man den Source schreibt. Die Nested Funktion ist also ein Hilfsmittel der Programmiersprache und dient nicht im speziellen der Lösung eines Programmierzieles im allgemeinen !!

Gruß hagen

[negaH]

Zitat:

Übrigens interessant zu sehen wieviele Meinungen es zu einem so "unwichtgen" Thema gibt

es gibt eigentlich nur 2 Meinungen, diejenigen die es als unsauber empfinden und diejenigen die es konzeptionell als richtig emfinden.
Unwichtig ist dieses gerade deswegen überhaupt nicht, da nur EINE Meinung richtiger als die andere sein MUSS !

Desweiteren ist eben auch der Punkt der PASCAL/Delphi konformen Schreibweise der Bezeichner, den Einrückungen und den Leerzeilen ein gleichbedeutender Punkt wie die neseted Funktionen. Grundsätzlich sind nämlich alle diese Punkte eine Frage nach dem besten Programmierstil und haben erst sekundär Auswirkung auf die erreichbare Funktionalität in den resultierenden Anwendungen.

Gruß Hagen

[Vitus]

hmmm ich versuche einfach immer mit Objekten zu arbeiten.

Im obigen Beispiel ist die Prozedur in der Klasse TTestKlasse - in so einem Fall habe ich bisher immer so gearbeitet dass ich die Funktion test in der Klasse als private deklariert hätte. Das Ergebnis wäre das gleiche, nur das der Code, in meinen Augen - und das ist lediglich meine subjektive Meinung - etwas übersichtlicher ist.
Und wenn man dieses nested Spielchen wirklich bis zu 4 Ebenen fortsetzt, wird es schon schwierig 3 Einrückungen von 4 zu unterscheiden

Zitat:

Worin besteht für dich der Unterschied zwischen kleinen und großen Projekten, in Bezug auf die Regeln der Modularisierung der Sourcen ??

Wenn ich schnell mal ein Programm brauche um.... keine Ahnung... in einem Text alle "Vitus" in "Sutiv" zu verwandeln, dann ist mir der Stil ziemlich wurscht. Das Programm brauche ich einmal und danach kommt es in die Tonne. Das wäre ein kleines Projekt. Gut - in diesem Fall braucht keiner eine solch eingebettete Funktion, aber Du weißt schon was ich meine

[Vitus]

ooooh - ich denke da besteht schon ein großer Unterschied!

Ich halte es für fraglich ob nested Funktion den OOP Konventionen entsprechen, hinsichtlich von Kapselung und Lesbarkeit.
Wer eine Leerzeile nicht schreibt, oder einen Kommentar wegläßt, der ändert ja am Programmteil des Sources nichts!

[negaH]

Hi Vitus,

ich glaube es ist schwer dir das Konzept als solches näher zu bringen.

Zitat:

Im obigen Beispiel ist die Prozedur in der Klasse TTestKlasse - in so einem Fall habe ich bisher immer so gearbeitet dass ich die Funktion test in der Klasse als private deklariert hätte. Das Ergebnis wäre das gleiche, nur das der Code, in meinen Augen - und das ist lediglich meine subjektive Meinung - etwas übersichtlicher ist.
Und wenn man dieses nested Spielchen wirklich bis zu 4 Ebenen fortsetzt, wird es schon schwierig 3 Einrückungen von 4 zu unterscheiden

Eben nicht. Es interessiert NICHT wieoft und wie tief man Verschachtelt, sondern es IST ein Hilfsmittel die Aufgaben des Programmes struktriert zu modularisieren.
Besteht in einer Klasse die NOTWENDIGKEIT das eine Funktionalität MEHRFACH an verschiedenen Stelle benutzt werden soll so ist eine nested Funktion eine schlechte Wahl.
Besteht dagegen die Notwendigkeit innerhalb nur EINER Methode einige identische Aufgaben klarer zu strukturieren dann ist die nested Funktion erstmalig die beste Wahl.
Übersichtlichkeit entsteht dann dadurch das sich der Programmierer IM Source auf lokal begrenzte Quellcode Zeilen beschränken kann. Er wird nun nachvollziehen woll was eine Procedure im einzelnen macht. Wird mit nested Funktionen gearbeitet so ist es ohne Probleme möglich sich auf Teillösungen von Teilproblemen zu konzentieren. Sind diese verstanden geht der Programmierer strukturell in seine Analyse exakt eine Ebene höher in der Verschachtelung der nested Funktionen. Somit ZWINGEN nested Funktion, so wie die Objekte, die Units usw. dem Programmierer eine strukturelle Sichweise des Problemes auf. DIES nenne ich eben PASCAL !! statt C, BASIC usw.

Zitat:

Zitat:

Worin besteht für dich der Unterschied zwischen kleinen und großen Projekten, in Bezug auf die Regeln der Modularisierung der Sourcen ??

Wenn ich schnell mal ein Programm brauche um.... keine Ahnung... in einem Text alle "Vitus" in "Sutiv" zu verwandeln, dann ist mir der Stil ziemlich wurscht. Das Programm brauche ich einmal und danach kommt es in die Tonne. Das wäre ein kleines Projekt. Gut - in diesem Fall braucht keiner eine solch eingebettete Funktion, aber Du weißt schon was ich meine

Siehst du, und ich mache bei KEINEM Source einen Unterschied in MEINEM Stil, WARUM auch ??
Denn statt mir einen schlechten Stil für kleine Projekte und einen guten Stil für große Projekte anzueigenen, arbeite ich bei JEDEM Projekt mit immer dem gleichem Still. Der Stil bestimmt also wie man ohne Probleme ein kleines Projekt exakt gleichgut warten, aufbauen und weitergeben kann, wie ein großes Projekt.


Gruß hagen

[Vitus]

püüüh nunja.. alles klar...

was aber kleine & große Projekte angeht:
Wann brauche ich jemals wieder einen Algorithmus der aus dem String "Vitus" "Sutiv" macht?!? Warum sollte ich in so einem Programm Zeilenlang Kommentare schreiben und ja auf Leerzeilen und Groß- Kleinschreibung achten, obwohl ich weiß dass es nach einer erfolgreichen Anwendung in der Versenkung verschwindet?!?

Sobald ich einen Code entwickel den ich später mal wieder gebrauchen kann, arbeite ich immer strukturiert...


Thema eingenistete Funktionen is für mich abgeschlossen, auch wenn ich Deine Meinung immer noch nicht teile *fg*
Ich bleib bei meinen Klassen, und arbeite, sobald es zuviele werden, einfach mit mehr units

Gruß
Vitus

[neolithos]

Zitat von Vitus:

was aber kleine & große Projekte angeht:
Wann brauche ich jemals wieder einen Algorithmus der aus dem String "Vitus" "Sutiv" macht?!? Warum...

Erstaunlicher weise meist schneller als einem Lieb ist! Jedenfalls ist es mir schon oft so gegangen. Deshalb bin ich froh das ich es genauso wie Hagen mache und jedes fast Project gleich behandle.

Große Projecte erhalten nur noch eine Txt-Abschnitt in dem Struktur und Konzepz erklärt, weil dies meist schlecht bei mehren 10000-ten von Code-Zeilen erkennbar ist.

Zitat von Vitus:

Thema eingenistete Funktionen is für mich abgeschlossen, auch wenn ich Deine Meinung immer noch nicht teile *fg*
Ich bleib bei meinen Klassen, und arbeite, sobald es zuviele werden, einfach mit mehr units

Gruß
Vitus

Du tust mir Leid.

Noch ein Beispiel für eine Sinnvolle Anw.

Delphi-Quellcode:

procedure T???.SortMyList;

  function AscSort(p1, p2 : PData)
  begin
    Result := CmpTxt(p1^.sName, p2^.sName);
  end;

  function DescSort(p1, p2 : PData)
  begin
    Result := not CmpTxt(p1^.sName, p2^.sName);
  end;

begin
  case fOrientation of
       orAsc: lstData.Sort(@AscSort);
       orDesc: lstData.Sort(@DescSort);  
  end;
end;

[negaH]

Die Programmier-Stil-Frage ist auch eine Frage nach der Disziplin des Programmierers. Damit meine ich nicht nur die Disziplin aus Prinzip, sowie ein Krümelkacker aus Trotz es immer gleich macht. Sondern eher die Erkenntnis das der Source eines Programmierers SEINE Disziplin erkennenlässt die er dazu benutzt um sein DENKEN als Arbeit zu organisieren. Programmieren ist eine Arbeit des Hirnes, das Denken. Ein guter und sauberer Programierstil erleichtert also das Denken, eg. die Arbeit des Programmierers.

Deshalb ist die Frage nach dem besten Programmierstil eine sehr wichtige Frage für uns alle.
Nun, jeder strukturierte Programmierstil ist somit die objektive Wirkung der rein subjektiven Arbeit. Über die Analyse eines Programierstil kann man demzufolge auch die subjektive Qualität der Arbeit des Programmieres objektiv einschätzen.

D.h. ein guter Programierstil kann nur dadurch entstehen das sich der Programmierer seines DENK-Prozesses als Arbeit BEWUSST ist. Über den Stil versucht er eine objektive Lösung zu finden darüber nachzudenken wie er demnächst effektiver Denken kann.

Hört sich vielleicht ein bischen abgehoben und kompliziert an, aber wenn man mal darüber nachdenkt ist es absolut logisch.

Da sich am Anfang die meisten Programmierer nur auf die Problemlösung konzentieren, also die Erzeugung eines Programmcodes der ein Problem lösst, wird der wichtige Punkt WIE man seine DENK Arbeit am besten PLANT übersehen.
Erst mit längerer Erfahrung wird ein Programmierer anfangen sich darüber Gedanken zu machen wie er überhaupt denken muß um ein Problem zu durchdenken. Ein gleichbleibender und logisch strukturierter Programierstil ist dafür Voraussetzung.

Demzufolge ist es einem solchen Programmierer egal WAS er für Probleme lösst, Hauptsache für ihn wird es WIE er ein Problem lösst.

Gruß Hagen