Delphi Quellcode ordnen

[SyntaxXx]

Guten Abend liebe User,
ich programmiere wirklich gerne in Delphi, doch je größer meine Projekte werden, desto unübersichtlicher werden diese.
Ich habe jetzt eine Anwendung, die bisher nur eine Unit benötigt.
Auf dieser ist meine GUI und dahinter meine Methoden.


Alles in allem habe ich jetzt mit Buttons, PupupMenüs und nem StringGrid über 30 Methoden.
Da verliere ich leider so langsam den Überblick.
Was macht ihr, um euren Code übersichtlicher zu gestallten?


Ich arbeite ab und an auch mal mit C#, und da muss ich sagen, dass mir das Prinzip mit Klassen und der Ordnerstruktur sehr viel besser gefällt.
Habt ihr ein paar Ratschläge, wie man die Übersicht bewahren kann?

[himitsu]

Zitat von SyntaxXx:

und da muss ich sagen, dass mir das Prinzip mit Klassen und der Ordnerstruktur sehr viel besser gefällt.

Auch mit mehreren Klassen (wozu ist Delphi denn sonst OOP) und Units arbeiten?

Wie heißt es so schön? Wer GUI und Code nicht trennt, ist selber Schuld.

Mit Regionen kann man auch bissl aufräumen (ausblenden).
Die Struktur (meistens über dem OI) sollte dir auch einen Überblick über Alles bieten, sowie das IDE Insight (F6).
Und Castalia, cnPack, GExperts usw. haben auch viele Helferlein.

[Dalai]

Zitat von SyntaxXx:

Was macht ihr, um euren Code übersichtlicher zu gestallten?

Den Code logisch auf mehrere Units aufteilen. Beispiel: Konstanten, die von mehreren Formularen benutzt werden, kommen in eine separate Unit. Alle Funktionen, Konstanten etc., die mit Executables zu tun haben (z.B. Ermittlung der Versionsnummer) kommen in eine separate Unit. Und natürlich wird die Logik von der GUI entkoppelt, d.h. eine Klasse, die irgendwelche nicht-sichtbaren Objekte verwaltet, hat nichts in einer GUI-Unit verloren.

Eben eine logische Trennung. Ja, manchmal ist es nicht einfach, diese Trennung einzuhalten, weil manche Dinge durchaus in mehrere Units passen. Aber anfangen muss man damit irgendwann.

MfG Dalai

[Perlsau]

Zitat von SyntaxXx:

Alles in allem habe ich jetzt mit Buttons, PupupMenüs und nem StringGrid über 30 Methoden.
Da verliere ich leider so langsam den Überblick.
Was macht ihr, um euren Code übersichtlicher zu gestallten?

Abgesehen von den bereits genannten wertvollen Hinweisen, wie man seinen Code übersichtlich gestaltet (Trennung GUI und Verwaltung, verstärkt Klassen einsetzen, Code auf mehrere Units aufteilen usw.) bin ich inzwischen weitgehend dazu übergegangen, mit Frames zu arbeiten statt z.B. mit PageControls oder zahlreichen Formularen. Frames werden im Hauptfenster angezeigt und enthalten die GUI sowie, je nach Umfang, auch einiges an Berechnungs- und Verwaltungskram. Bei Datenbank-Anwendungen setzt man Datenmodule ein, die die Verbindungs-Komponenten aufnehmen und die gesamten Datenbank-Methoden enthalten.

Auch eine Sortierung der Variablen und Methoden entgegen der von Delphi beim Implementieren gewählten Stelle kann hilfreich sein. So sortiere ich z.B. die Komponenten-Variablen stets entsprechend dem GUI-Aufbau:

Delphi-Quellcode:

UNIT UnitMain;

INTERFACE

USES
  Windows, Messages,
  ...;

TYPE
  TFormMain = CLASS(TForm)
    StatBar              : TJvStatusBar;
    Panel_Main           : TPanel;
    Panel_Navi           : TPanel;
    TrBt_Append          : TJvTransparentButton;
    TrBt_Delete          : TJvTransparentButton;
    TrBt_Edit            : TJvTransparentButton;
    TrBt_Post            : TJvTransparentButton;
    TrBt_Cancel          : TJvTransparentButton;

    AktionsListe         : TActionList;
    AL_DB_Close          : TAction;
    AL_ED_Append         : TAction;
    AL_ED_Delete         : TAction;
    AL_ED_Edit           : TAction;
    AL_ED_Post           : TAction;
    AL_ED_Cancel         : TAction;
    AL_WN_Zentrale       : TAction;

    HauptMenu            : TMainMenu;
    HM_DB                : TMenuItem;
    HM_DB_Close          : TMenuItem;
    HM_ED                : TMenuItem;
    HM_ED_Append         : TMenuItem;
    HM_ED_Delete         : TMenuItem;
    HM_ED_Edit           : TMenuItem;
    HM_ED_Post           : TMenuItem;
    HM_ED_Cancel         : TMenuItem;
    HM_TO                : TMenuItem;
    HM_WN                : TMenuItem;
    HM_WN_Zentrale       : TMenuItem;
    HM_WN_Video          : TMenuItem;
    HM_WN_VideoAkt       : TMenuItem;
    HM_WN_Personen       : TMenuItem;
    HM_WN_PersAkt        : TMenuItem;
    HM_WN_FSK            : TMenuItem;

    Procedure FormCreate(Sender            : TObject);
    Procedure FormShow(Sender              : TObject);
    Procedure FormActivate(Sender          : TObject);
    Procedure FormCloseQuery(Sender        : TObject; var CanClose: Boolean);
    Procedure FormClose(Sender             : TObject; var Action: TCloseAction);
    Procedure FormDestroy(Sender           : TObject);
    Procedure AL_DB_CloseExecute(Sender    : TObject);
    Procedure AL_ED_AppendExecute(Sender   : TObject);
    Procedure AL_ED_DeleteExecute(Sender   : TObject);
    Procedure AL_ED_EditExecute(Sender     : TObject);
    Procedure AL_ED_PostExecute(Sender     : TObject);
    Procedure AL_ED_CancelExecute(Sender   : TObject);
    Procedure AL_WN_ZentraleExecute(Sender : TObject);

Das sind alle Komponenten auf meiner Mainform, und dennoch ist das Programm insgesamt äußerst umfangreich (mehr als 800.000 Zeilen). Alles andere liegt in Frames oder im Datenmodul. Damit bleibt das hier ziemlich übersichtlich.

Private Methoden ordne ich ebenfalls so an, daß ich sie leicht wiederfinde, auch wenn ich gerade mal nicht wissen sollte, wie die Methode genau heißt. Im Implementation-Teil kommen immer zuerst die privaten Methoden in derselben Reihefolge, wie sie im PRIVATE-Abschnitt stehen:

Delphi-Quellcode:

PRIVATE { Private-Deklarationen }

    Procedure StatusBarAktuell;
    Procedure EinstellungenLesen;
    Procedure EinstellungenSchreiben;
    ...

  PUBLIC  { Public-Deklarationen  }
  END;

VAR
  FormMain : TFormMain;

IMPLEMENTATION
{$R *.dfm}
{ TFormMain }

Uses
  UnitData, GLD, DatBankEdit, Fram_Main, ...;

Var
  DBE                 : TDatBankEdit;
  ...

// ##### PRIVATE METHODEN ###############################################################################################################

// ---------- Statusbar aktualisieren -------------------------------------------------------------------------------------------- Privat
Procedure TFormMain.StatusBarAktuell;
begin
  ...

Public-Methoden habe ich in meinen Mainforms keine, da letztgenannte niemals von anderen Units referenziert werden. Am Ende stehen dann die Ereignis-Behandlungen, und zwar ebenfalls in einer mir sinnvoll erscheinenden Reihenfolge:

Delphi-Quellcode:

// ##### EREIGNISSE #####################################################################################################################

// ---------- On Create ------------------------------------------------------------------------------------------------------ Ereignisse
Procedure TFormMain.FormCreate(Sender: TObject);
begin
  ...
end;

// ---------- On Show -------------------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.FormShow(Sender: TObject);
begin
  ...
end;

// ---------- On Activate ---------------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.FormActivate(Sender: TObject);
begin
  ...
end;

// ---------- On Close Query ------------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.FormCloseQuery(Sender: TObject; Var CanClose: Boolean);
begin
  ...
end;

// ---------- On Close ------------------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.FormClose(Sender: TObject; Var Action: TCloseAction);
begin
  ...
end;

// ---------- On Destroy ----------------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.FormDestroy(Sender: TObject);
begin
  ...
end;

// ---------- Programm beenden ----------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.AL_DB_CloseExecute(Sender: TObject);
begin
  Close;
end;

// ---------- Append --------------------------------------------------------------------------------------------------------- Ereignisse
Procedure TFormMain.AL_ED_AppendExecute(Sender: TObject);
  ...

Um gleich erkennen zu können, wo genau ich mich befinde, habe ich mir angewöhnt, ausnahmslos jeder Function und Procedure einen Kommentar-Header zu verpassen, der mir auf Anhieb zeigt, was die Methode macht und wo sie steht (z.B. Private oder Ereignisse). Auch die Ereignisse ordne ich so, daß oben die Start- und Ende-Ereignisse stehen, danach Reaktionen auf Komponenten-Ereignisse (hier nur ActionList-Ereignisse). Mit dieser Art & Weise, meinen Quellcode zu gestalten, komme ich seit Jahren ausgezeichnet zurecht.

Natürlich schreibe ich die ganzen Kommentarzeilen nicht bei jedem Projekt oder bei jeder Unit neu, sondern habe mir dafür ein Default-Projekt angelegt, das natürlich noch viel mehr grundlegende Sachen enthält, die ich aus meiner Erfahrung heraus in jedem Projekt benötige.

[baumina]

Sieht sehr ordentlich aus, Perlsau, wobei ich persönlich Kommentare wie "On Create" über der Procedure "FormCreate" als nutzlos betrachte.

[Perlsau]

Zitat von baumina:

Sieht sehr ordentlich aus, Perlsau, wobei ich persönlich Kommentare wie "On Create" über der Procedure "FormCreate" als nutzlos betrachte.

Danke, Baumina, endlich weiß das mal jemand zu würdigen

Die Kommentare über den "offensichtlichen" Methoden stehen dort auch nur aus gewissermaßen ästhetischen Gründen und sind davon abgesehen in der Tat nutzlos – oder nein, nicht ganz, denn den Kommentar habe ich immer schneller im Fokus als den Methodennamen. Hab ich aber bereis in meinem Default-Projekt so angelegt und muß daher auch nicht neu getippt werden

Das Ganze sollte auch nur ein Beispiel sein. Die Frage lautete ja: Wie formatiert ihr euren Quellcode?

[Captnemo]

Finde ich ja rein optisch auch sehr schön, und für die Übersicht eigentlich auch nett.
Aber unabhängig von der Sinnhaftigkeit, die ja sowieso im Auge des Betrachters liegt (ist absolut nicht abwertend gemeint), würde mir das persönlich zu viel Zeit kosten, bei jeder Methode eine solche Kommentarzeile einzufügen. Es sei denn, sie enthält tatsächlich Informationen, die ich aus dem Methodenname und den Parametern nicht sowieso rauslesen kann. Zumal ja auch noch die Kommentare dazu kommen, die man sowieso machen sollte.

Wenn sich eine solche Zeile natürlich automatisch erzeugen ließe, dann wäre das was anderes.

[Perlsau]

Es mag für dich auf den ersten Blick so aussehen, als würde ich mit dem Einfügen von Kommentarzeilen unverhältnismäßig viel Zeit verschwenden. In Wirklichkeit kopiere ich einfach eine bereits vorhandene Kommentarzeile und füge sie über der neuen Methode ein. Danach muß ich nur noch den Text ändern (zuvor auf Überschreiben umschalten, damit die Formatierung nicht durcheinanderkommt). Das geht bei mir quasi (halb-)automatisch, weil ich das schon sehr lange so handhabe und beinahe täglich stundenlang am Coden bin.

Die für diese Kommentarzeilen aufgewandte Zeit spare ich dann beim Suchen & Finden einer Codestelle zig-fach wieder ein. Und wie bereits oben erwähnt: Ich verfüge über etliche Default-Projekte, die bereits solche Kommentarzeilen enthalten. Vielleicht sollte ich noch erwähnen, daß ich meine Tastatur blind beherrsche (hatte vor 36 Jahren in der Schule Schreibmaschinen-Unterricht und diese Fähigkeit immer durch Übung gepflegt und ausgebaut). Wenn ich Leuten was am PC zeige, muß ich mich immer bremsen, denn das geht oft so schnell, daß ein Beobachter gar nicht mitbekommt, was ich da gerade gemacht habe.

[jaenicke]

Ich benutze lieber Addons wie CodeExplorer. Da brauche ich keine Kommentare um zu sehen was private ist usw. oder für die Navigation. Das wird automatisch farblich in der Übersicht markiert und ich brauche nur drauf zu klicken um zum Code zu kommen. Das hat den Vorteil, dass ich in fremdem Code, auch dem der RTL z.B. genauso schnell navigiere wie in eigenem.

Ich weiß natürlich nicht wie das bei dir ist, aber ich kenne andere, die auch sehr auf Kommentare und hochspezielle Formatierung setzen, und bei fremdem Code oder beim Debuggen in den Delphi Quelltexten teilweise ganz verloren sind, teilweise extrem langsam sind.

[Perlsau]

Zitat von jaenicke:

Ich benutze lieber Addons wie CodeExplorer. Da brauche ich keine Kommentare um zu sehen was private ist usw. oder für die Navigation. Das wird automatisch farblich in der Übersicht markiert und ich brauche nur drauf zu klicken um zum Code zu kommen. Das hat den Vorteil, dass ich in fremdem Code, auch dem der RTL z.B. genauso schnell navigiere wie in eigenem.

Einen CodeExplorer konnte ich in meinem Delphi2009 nicht finden, und auf der entsprechenden Website wären 100 Euro dafür fällig. Das gibt mein Budget nicht her. Kommt halt immer auch drauf an, in welchem Umfeld man arbeitet bzw. was man mit seiner Arbeit verdient.

Zitat von jaenicke:

Ich weiß natürlich nicht wie das bei dir ist, aber ich kenne andere, die auch sehr auf Kommentare und hochspezielle Formatierung setzen, und bei fremdem Code oder beim Debuggen in den Delphi Quelltexten teilweise ganz verloren sind, teilweise extrem langsam sind.

Das ist in der Tat ein Manko meiner Methode, das kann ich aus eigener Erfahrung bestätigen. Oft ist aber auch bereits ein fast vollständig unkommentierter Fremdcode daran beteiligt, daß es längere Zeit in Anspruch nimmt, ihn zu analysieren. Ich will mich aber von Fremdcode nicht unbedingt dazu verleiten oder bedrängen lassen, meine Formatierungsmethoden gravierend zu ändern oder das Kommentieren so stark einzuschränken, wie ich das gelegentlich bei Fremdcode sehe. Gerade für einen Programmierer, der Fremdcode zu bearbeiten hat, ist es äußerst hilfreich, wenn er bereis am Kommentar sehen kann, was diese oder jene Routine tut. Wie sie's genau tut, muß er dann natürlich im Code selbst herausfinden. Die Empfehlung, sprechende und aussagekräftige Bezeichner auch für Methoden zu verwenden, beherzigen meiner bescheidenen Erfahrung nach noch immer sehr wenige Delphi-Programmierer. Nicht selten würde ein Bezeichner aber auch zu lang werden, wenn man ihn derart umbenennen wollte, daß aus dem Namen bereits die Funktion ersichtich ist. Deshalb, so scheint mir, verwenden viele Abkürzungen, die sie nach ein paar Jahren dann oft selbst nicht mehr auf Anhieb verstehen.

Naja, wie gesagt, dieser Thread soll ja nur, wie ich das verstanden hatte, dazu dienen, Beispiele für Code-Formatierungen zu zeigen. Was da jetzt wem besser oder ungünstiger erscheint, wurde bereits in zahlreichen ähnlichen Threads bis zum Anschlag durchgeackert

Zitat von SyntaxXx:

Was macht ihr, um euren Code übersichtlicher zu gestallten?
Habt ihr ein paar Ratschläge, wie man die Übersicht bewahren kann?

Übrigens muß man die Anmerkung, der eigene Beitrag enthielte keine Kritik, nur dann anbringen, wenn der Beitrag trotzdem Kritik enthält. Nein, ich habe nichts gegen Kritik einzuwenden.