Wie lang sind eure Delphi Quellen?

[WM_CLOSE]

Guten Tag,
heute sitze ich gerade an einer Unit, die ich ändern soll.
Die ist ohne whitespaces ca 17000 Zeilen lang.:wall::wall::wall:
Kennt einer von euch solche Situationen, wo man langsam einen Krampf in den Scrollfinger bekommt?

[mleyen]

Strg+Scroll, Codemovement (nicht immer 100% funktionsfähig) und Regions helfen.
Aber eine Unit 17k Zeilen :shock::shock:

[himitsu]

Jupp, kenn ich, meine himXML.pas war zwischenzeitlich auf 19.000 (jetzt nur noch 13.000).

mit ein paar Regions

Delphi-Quellcode:

{$REGION 'TKlasseA'} ... {$ENDREGION}

waren die Wege dan kürzer, ansonsten helfen cnPack oder GExperts, wo man z.B. über Comboboxen direkt zu Funktionen navigieren kann.

PS: Codeteile in Include-Dateien auszulagern verkürzt zwar auch die Wege, macht es aber leider noch unübersichtlicher und das Debuggen schwerer.
Ansonsten bleibt dir halt nur der Weg, alles auf mehrere Units aufzuteilen. :stupid:

[Bummi]

ein paar Altlasten in der Art habe ich auch noch, gegf. Refactoring und splitten...

[WM_CLOSE]

ein weiteres Problem ist auch, dass sich Delphi enorm viel Zeit lässt beim bearbeiten der Unit:
wenn ich ein Codestück markiere* und dann rechtsklicke um dann Umgeben->Region auszuwählen warte ich erst mal zwei Minuten bis das Popup Menu aufgeht und dann noch eine halbe bis die Region da ist.

Ich benutzte einen Athlon 64 X2 3800+ @1.79 Ghz mit 2GB RAM
Mag sein, dass das eine Geduldsfrage ist, aber bei mir Zuhause (i7 920 und 6GB) fühlen sich 3 Instanzen von Delphi flüssiger an als 1 bei dem besagten Rechner.

*Was auch regelmäßig zu Abstürzen führt.

[s.h.a.r.k]

Bei so einer länger versuche ich immer bestimmte Teile auszulagern, sodass ich sinnvoll strukturierte Teile habe, wobei das halt nicht immer möglich ist. Unschön bei sowas ist auch, wenn ich dann mal mehrere dieser Teile brauche, muss ich mehr als eine Unit einbinden und dabei am besten immer genau wissen, wo was drin ist. Bin jetzt erst gerade dabei auf die XML-Dokumentation umzustellen, weswegen ich halt auch noch teilweise in den Code schauen muss.

Pauschal weiß ich jetzt nicht, wie lange die SysUtils ist, aber wenn diese z.B. aus 3-5 Parts bestehen würde und du jedes mal nachdenken müsstest, wo was gerade steckt, was du brauchst, wäre es ein wenig blöd ;) Ebenso ist doch der Compiler so intelligent und wirft teile raus, die von deinem Code nicht verwendet werden -- für die Wartung ists halt ein bisschen blöd, aber ansonsten finde ich es akzeptabel.

[igel457]

Ich achte eigentlich darauf, dass meine Units im Normalfall (mit Whitespaces und Dokumentation) nicht länger als 2000-3000 Zeilen werden. Wenn man seinen Code dann nicht sinnvoll aufteilen kann, so hat man irgendwo einen Designfehler gemacht. Zudem sollten die einzelnen Teile relativ wenige Dependencies haben (am besten nur zu so was wie SysUtils, Classes, Types etc.). Wenn man sich daran hält, bekommt man meistens automatisch schönen, modularen Code, der sich einfach warten lässt.

Ausnahmen von dieser Regel sind in der Tat kompakte Bibliotheken mit oft gebrauchten Funktionen (sowas wie SysUtils, Classes, XML-Parser, etc.), für die man nicht dutzende einzelne Units einbinden möchte.

[himitsu]

Sowas entsteht bei mir entweder, bei mehreren verketteten Klasen oder wenn ich eben alles möglichst in einer Unit hätte.

[WM_CLOSE]

Eine der kklassen hat 100! properties, mit je Getter und Setter das sind 300 Zeilen nur im interface Klasse. Die Klasse hat >1000 Zeilen nur im Interfaceteil, Die Unit ca 2000. Wohlgemerkt ohne Whitespaces.

Waaaaaah!:wall::wall::kotz::kotz:

Das ganze ist wohl aus der reinen Faulheit, das ganze ordentlich aufzuteilen entstanden.
Immer nur weiter ein neues Feature hinzugefügt ohne Rücksicht auf Verluste.
Teilweise muss ich noch Funktionen aus der GUI mit in die Unit nehmen, die wurden damals einfach in verschiedene Projekte kopiert.

[ChrisE]

:-)

Unit Windows.pas inkl. Whitespaces D2007 32k+ Zeilen ;-)

Gruß, Chris

[bernau]

Manchmal kann man es leider nicht ändern, daß eine Unit zu Lang wird.

Ich habe z.B. eine Unit mit 60 Klassen. Jede klasse muss die andere Klasse kennen. Das geht nur mit einer Foreward-Deklaration. Das geht wiederum nur in einer einzigen Unit. Die längste Unit hat glaube ich so ca. 34.000 Zeilen.

[Florian Hämmerle]

Was sind das für Klassen wenn ich fragen darf?

mfg Florian

[bernau]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1082486)

Was sind das für Klassen wenn ich fragen darf?

Für meine Software gib es komplexe (vorgegebene) XML-Strukturen. Jedes Element dieser XML-Struktur ist bei mir eine Klasse. In der XML-Definition kann ElementA z.B. 4 Childs vom ElementB haben. ElementB darf aber auch wider ein Child vom Type ElementA haben. Damit müssen die sich gegenseitig kennen. DAfür brauche ich dann eine Foreward-Deklaration.

Mit den Klassen bilde ich natürlich nicht nur die XML-Struktur ab, sondern diese Klassen haben auch eine gewisse Logik und berechnen etwas. Daher wird dann die Unit etwas größer.

[RWarnecke]

Wenn ich das hier alles so höre, dann sind ja meine 4000 Zeilen (ink. Leerzeilen & Kommentaren) in einer Unit lächerlich. :cyclops:

[Teekeks]

Und wie ich mich erst fühle mit 2000 ^^

[turboPASCAL]

Zitat:

Wie lang sind eure Delphi Quellen?

Mal so und mal so. :mrgreen:

[wicht]

Längste Unit mit Leerzeilen und sehr wenigen Kommentaren ist 1521 Zeilen lang - die gute LanguageObjects.pas von Lingus, wo es viele Klassen gibt, von denen sich viele kennen müssen..

[Hansa]

Ich würde mir mal eher die Dateigrössen ansehen und nicht die Leerzeilen irgendwie verrechnen. :shock: Und da hat es sich bewährt, sich an die alte 64 k Grenze zu halten. Habe in einem alten BP7 Programm geguckt. 2 Dateien für eine Unit. Per Include eben. 56 K und 32 K ergibt in Zeilen zusammen ca. 2900. Warum ich das aufsplitten musste ? :gruebel: Da ich das aber so gemacht hatte, wird das schon seinen Grund haben. Auf genau 64 K zu achten macht mittlerweile ja keinen grossen Sinn. Damals war das eben das absolute Limit für diverse Editoren. Aber orientieren kann man sich schon an dem altbewährtem, auch wenn es anders auch 'geht'. 8-) Die heutigen Delphi Units liegen überwiegend unter 2000 Zeilen. Es gibt übrigens noch eine Faustformel : Prozedur nie grösser als 2 DIN A 4 Seiten machen, sonst werden nicht nur die Units unübersichtlich, sondern sogar die Prozeduren. Und das ist noch schlimmer !

[WM_CLOSE]

224 Seiten:pale:
Ich hab mal meinen Chef gefragt, ob ich das ausdrucken darf:lol:

[turboPASCAL]

Falls Du Endlospapier und 'n passenden Nadeldrucker brauchst, ich hab da noch was über... :stupid:

[Blup]

Zitat:

Zitat von bernau (Beitrag 1082490)

Zitat:

Zitat von Florian Hämmerle (Beitrag 1082486)

Was sind das für Klassen wenn ich fragen darf?

Für meine Software gib es komplexe (vorgegebene) XML-Strukturen. Jedes Element dieser XML-Struktur ist bei mir eine Klasse. In der XML-Definition kann ElementA z.B. 4 Childs vom ElementB haben. ElementB darf aber auch wider ein Child vom Type ElementA haben. Damit müssen die sich gegenseitig kennen. DAfür brauche ich dann eine Foreward-Deklaration.

Mit den Klassen bilde ich natürlich nicht nur die XML-Struktur ab, sondern diese Klassen haben auch eine gewisse Logik und berechnen etwas. Daher wird dann die Unit etwas größer.

Ein Grund sich gedanken zu machen, ob man die ganze Objektstruktur nicht auf Interfaces umstellt. Dazu eine Faktory, bei der sich alle implementierenden Klassen registrieren. Schon kann jede Klasse ihre eigene Unit bekommen.

[bernau]

Zitat:

Zitat von Blup (Beitrag 1083147)

Ein Grund sich gedanken zu machen, ob man die ganze Objektstruktur nicht auf Interfaces umstellt. Dazu eine Faktory, bei der sich alle implementierenden Klassen registrieren. Schon kann jede Klasse ihre eigene Unit bekommen.

Ähm, ... ja. Habe mit Interfaces noch nicht gearbeitet. Faktory??????

Das ganze ist schon 7 Jahre alt. Habe damals eine Klasse geschrieben, die sich um das Lesen und schreiben der XML-Dateien kümmert. Davom leite ich dann einfach neue Klassen ab, die dann die Kind-Elemente und Attribute als Property definiert.

Ich finde es persönlich nicht schlimm, wenn man dann eine "lange" pas-Datei bekommt. Mit den Navigationsmöglichkeiten der IDE (inkl. unterstützung durch die GExperts) findet man sich sehr gut auch in langen Codes zurecht.

Aber man sollte ja immer mal über den Tellerrand hinausschauen. Gibt es ein Tutorial über Interfaces?

[angos]

Jup gibt es,

um in Interfaces reinzukommen ist das hier ganz gut: Inteface Tutorial

Gruß
Ansgar

[WladiD]

Sehr interessantes Thema. Meiner Meinung nach gibt es keine pauschale Regel, wie groß eine Unit sein darf. Versucht man auf Biegen und Brechen die Unit aufzusplitten, nur um einen besseren Überbrlick zu bekommen, so sind andere Probleme vorprogrammiert. {$REGION}{/REGION} hatte ich auch mal eine Zeitlang verwendet, doch irgendwie ist der ganz Code-Folding-Krempel nicht mein Ding gewesen.

Als Paradabeispiel für RIESIGE Units fällt mir spontan VirtualTrees.pas ein: Es ist 1,29 MB groß und hat über 36k Zeilen (ok, inkl. Kommentare und Whitespaces). Aber ist es deswegen automatisch ein Konzeptionsfehler? Ich denke nicht, die ist sehr modular aufgebaut und kann angepasst werden, bis der Arzt kommt.

Wie navigiert man dann effizient?
Delphi-Klassen-Explorer und [Strg]+([Shift]+)[[0]..[9]] :-D

[bernau]

Zitat:

Zitat von angos (Beitrag 1083165)

Jup gibt es,

um in Interfaces reinzukommen ist das hier ganz gut: Inteface Tutorial

Gruß
Ansgar

Interssantes Tutorial. Aber mir erschliesst sich noch nicht ganz, was "Interfaces" für mich für Vorteile haben.

[Assarbad]

Zitat:

Zitat von bernau (Beitrag 1083248)

Interssantes Tutorial. Aber mir erschliesst sich noch nicht ganz, was "Interfaces" für mich für Vorteile haben.

Zuerst haben sie mal den Vorteil, daß sie sprachunabhängig sind. Egal ob du VB, Delphi oder C++ benutzt (und sogar C), Interfaces bieten eine binärkompatible Schnittstelle.

[Namenloser]

Vorteil ist, dass du mehrere Interfaces in einer Klasse implementieren kannst, was bei abstrakten Klassen nicht geht, weil in Delphi keine Mehrfachvererbung erlaubt ist. Außerdem kannst du von jeder beliebigen Klasse ableiten und musst nicht von einer bestimmten Klasse ableiten.

[mquadrat]

Ich probier nicht über die 2000 / 3000 Zeilen zu kommen. Bei manchen Klassen lässt es sich aber nicht verhindern. Allein Properties und Getter und Setter erzeugen ja haufenweise Zeilen. Delphi ist nun mal nicht die kompakteste Sprache.

[Assarbad]

Apropos: bei den riesigen Units ist noch keiner auf die Idee gekommen es zumindest in Include-Dateien auszulagern?

[Der.Kaktus]

ich programmiere seit 1981...von Assembler(Grossrechner)..Turbo Pascal..bis D7..aber mehr als 1500 Zeilen pro Unit habch noch net geschafft (ok assembler damals gabs mal 3000) *gg*
Diese Interface Geschichte kenne ich nicht..vorallem wegen der Generierung der ID..aber wozu?? und Auslagerung Include?..*gruebel*..

[Florian Hämmerle]

Zitat:

Zitat von mquadrat (Beitrag 1083260)

Ich probier nicht über die 2000 / 3000 Zeilen zu kommen. Bei manchen Klassen lässt es sich aber nicht verhindern. Allein Properties und Getter und Setter erzeugen ja haufenweise Zeilen. Delphi ist nun mal nicht die kompakteste Sprache.

Naja, für Getter und Setter benötigst du aber eigentlich immer zwei Methoden, egal in welcher Sprache
-> Funktionskopf + begin + Anweisungen + end; brauchen eben mal mindestens 4 Zeilen wenn man es standardmäßig formatiert
:gruebel:

[Namenloser]

Zitat:

Zitat von Assarbad (Beitrag 1083270)

Apropos: bei den riesigen Units ist noch keiner auf die Idee gekommen es zumindest in Include-Dateien auszulagern?

Ich finde, mit Include-Dateien verliert man imo eher Übersicht. Wenn man tatsächlich seinen Code in mehrere Units trennt, gewinnt man Übersicht, da man seinen Code modularisieren muss (sonst gibts zirkuläre Abhängigkeiten und der Compiler meckert). Includes sinnvoll einzusetzen ist in Delphi hingegen schwierig, da man ja zwangsläufig oben den interface- und unten den implementation-Teil hat, sodass man immer mindestens zwei Dateien anpassen muss, wenn man eine Sache ändert. Da fährt man mit einer großen Datei besser, zumal die sich die Navigation innerhalb einer Unit dank IDE ja leicht gestaltet.

[himitsu]

Zitat:

Zitat von Assarbad (Beitrag 1083270)

Apropos: bei den riesigen Units ist noch keiner auf die Idee gekommen es zumindest in Include-Dateien auszulagern?

Wie schon erwähnt ... ICH ... nur hatte es sich (zumindestens damals in Delphi 7) nicht als optimal erwiesen.

- Der Debugger und vorallem der Compiler kamm nicht wirklich damit klar, bzw. man wußte nicht immer wo man sich grade befindet, bzw. wo sich nun wirklich der gemeldete Compilerfehler befindet.

[Bummi]

Zitat:

Apropos: bei den riesigen Units ist noch keiner auf die Idee gekommen es zumindest in Include-Dateien auszulagern?

ich habe es eine Zeit lang gemacht, allerdings waren die Kollegen die den Code später weiterverwenden sollten nicht sehr angetan....

[implementation]

[OT]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1083278)

Zitat:

Zitat von mquadrat (Beitrag 1083260)

Ich probier nicht über die 2000 / 3000 Zeilen zu kommen. Bei manchen Klassen lässt es sich aber nicht verhindern. Allein Properties und Getter und Setter erzeugen ja haufenweise Zeilen. Delphi ist nun mal nicht die kompakteste Sprache.

Naja, für Getter und Setter benötigst du aber eigentlich immer zwei Methoden, egal in welcher Sprache
-> Funktionskopf + begin + Anweisungen + end; brauchen eben mal mindestens 4 Zeilen wenn man es standardmäßig formatiert
:gruebel:

Vergleichen wir mal Delphi und C#:

Delphi-Quellcode:

type
  TKlasse = class(TObject)
  protected
    FX: Integer;
    procedure SetX(const aX: Integer);
    function GetX: Integer;
  public
    property X: Integer read GetX write SetX;
  end;

procedure TKlasse.SetX(const aX: Integer);
begin
  FX := aX;
end;

function TKlasse.GetX: Integer;
begin
  Result := FX;
end;

Code:

class Klasse
{
  protected int x;
  public int X
  {
    get { return x; }
    set { x = value; }
  }
}

Schon ein Unterschied, oder? :zwinker:
(ohne jetzt Werbung für C# machen zu wollen ...)
[/OT]

[mleyen]

Delphi-Quellcode:

TKlasse = class(TObject)
protected
  FX: Integer;
public
  property X: Integer read FX write FX;
end;

Und include-files versuch ich auch zu vermeiden wo es nur geht, die Unitgröße wird dadurch eig auch nicht kleiner.:)

[mquadrat]

Ohne Getter und Setter ist das keine Kunst kürzer zu werden. :lol:

[mleyen]

Das sind getter/setter, außer das der compiler direkt auf die Variable zugreift.
Der Abstraktionsgrad bleibt erhalten und man kann immer ein get()/set() draus machen, falls es mal notwendig wird.

Aber ich such schon ewig nach einer sinnvollen Situation für ein get(). Hast du eine für mich?

[mquadrat]

Zum Beispiel Lazy Loading von Objekten. Oder berechnete Properties, die gar keine Member-Variable haben. Oder Properties von Decorator-Klassen.

Aber stimmt schon, solange man kein Get() braucht muss man es auch nicht hinschreiben.

[himitsu]

Diese Codeschlangenbildung vom C kann man in Delphi auch machen und schon wird es ebenfalls kürzer. :roll:

Delphi-Quellcode:

type
  TKlasse = class(TObject)
  protected
    var FX: Integer;  procedure SetX(const aX: Integer);  function GetX: Integer;
    var FY: Integer;  procedure SetY(const aY: Integer);  function GetY: Integer;
  public
    property X: Integer read GetX write SetX;
    property Y: Integer read GetY write SetY;
  end;

procedure TKlasse.SetX(const aX: Integer);  begin  FX := aX;  end;
function  TKlasse.GetX: Integer;            begin  Result := FX;  end; 
procedure TKlasse.SetY(const aX: Integer);  begin  FY := aY;  end;
function  TKlasse.GetY: Integer;            begin  Result := FY;  end;

und wenn man dagegen C# mal einrückt, dann sieht das gleich ganz anders aus :tongue:

Code:

class Klasse
{
  protected 
    int x, y;
  public
    int X
    {
      get 
      { 
        return x; 
      }
      set 
      { 
        x = value; 
      }
    }
    int Y
    {
      get 
      { 
        return y; 
      }
      set 
      { 
        y = value; 
      }
    }
}

Abgesehn davon, daß ich diese casesensitive Namensbehandlung nicht wirklich als gut leserlich empfinde.