Präfix oder Suffix - Wie haltet Ihr es mit der Namensgebung?

[Sir Rufo]

Bei der Bezeichnung der Formulare mache ich es mir ganz einfach:

Die MainForm-Klasse heißt TMainForm und liegt in der Unit Forms.MainForm .
Eine Dialog-Form heißt TFooDialog in der Unit Dialogs.FooDialog .

Man könnte somit sagen, der Name folgt der Funktion

[mm1256]

Zitat von Sir Rufo:

Die MainForm-Klasse heißt TMainForm und liegt in der Unit Forms.MainForm .
Eine Dialog-Form heißt TFooDialog in der Unit Dialogs.FooDialog .

Man könnte somit sagen, der Name folgt der Funktion

Macht halt jeder so, wie er zurecht kommt. Bei größeren Projekten muss man halt dann "eventuell" mit kleinen Einschränkungen leben. Beispiel: Wenn ich meine App mit derzeit 18 Modulen nehme und dazu einen Modulstarter der vor dem Start mit FindWindow() schaut, ob das Modul bereits läuft, muss man schon über die Caption gehen, und nicht mehr über die Fensterklasse. Auch beim Versenden von Messages an die eigenen Apps/Module wird's ein bisserl schwieriger.

[Sir Rufo]

Ich würde dafür niemals die Caption der Form nehmen.

Dafür gibt es etwas OOP-konformes: TObject.Equals( Obj: TObject );

[mm1256]

Wir reden aneinander vorbei. Das nützt dir halt leider nichts, wenn mehrere Instanzen (Module) mit derselben Klasse "TMainForm" am Laufen sind

BTW Was glaubst du wieviel "TForm1" von fremden Anwendungen ich auf meinem PC finde? Da sieht man dann sofort, wo Delphi-Programmierer am Werk waren

[Dejan Vu]

Wieso definierst Du dir nicht einfach eine Message ('WM_MyMessage') und sendest die per Broadcast an alle Fenster. Deine eigenen Fenster antworten dann auf diese message mit ihrem Handle und einer ID. Daran kannst Du dann im Sender genau den Empfänger ermitteln, den Du willst. Und zwar *ohne* die Caption zu verwenden.

Ich finde das sauberer als mit FindWindow. Aber wenn sich bei Dir die Caption eh nie ändert (oder das Fenster gar unsichtbar ist und nur als Kommunikationsplattform dient), dann ist das mindestens genauso gut.

Zitat von Captnemo:

Da ich mir das CN-Pack installiert habe, werden bei Komponenten auf der Form diese gleich automatisch umbenannt.

Das kann GExperts auch.

[Rollo62]

Nur mal ein Beispiel, damit ihr nicht ständig auf der Wolle-Klasse besteht.

Code:

Ein FormName beginnt immer mit dem Präfix "Frm", z.B. "FrmKunden". Ist es ein Hauptformular heißt die Unit "Main_Kunden.pas", ist es ein modaler Dialog entsprechend "Dlg_Kunden.pas". Bei DB-Anwendungen heißt die entsprechende Datenmodul-Unit "Dat_Kunden.pas". Die Interface-Procedure zum Anzeigen eines Formularess (ich erzeuge generell alle Formulare zur ....

Das wäre bei mir:

Code:

KundenFrm.pas
KundenDm.pas
KundenData.pas

Und schon habe ich lesbaeren Code, der sich auch noch sehr gut mit Codevervollständigung verträgt.
Das meinte ich mit "Klassenähnlich".

Ausserdem habe ich nicht immer die Zeit für jede mögliche Sub-Klasse diese auch auszugliedern.
Manchmal muss es Q&D gehen.
Über diese Schreibweise ist der Zusammenhang dann schonmal vorgemerkt, und ich kann dann später leicht eine Klasse draus machen.

Rollo

[Dejan Vu]

Leider ist das primäre Programmiermodel von Delphi (TDataModule, Komponenten) nur bedingt geeignet, bei komplexeren Projekten ein objektorientiertes Design durchzuziehen. Da muss man dann eben zu solchen Nomenklaturkrücken greifen.

Ähnlich ist das bei SQL, das auch keine Namespaces und Klassen vorsieht: Hier verwendet man Schemaspaces, um ein wenig Ordnung in das Chaos zu bringen. Das entspricht in etwa dem Bestreben, den Namen der Entität ("Kunde") als Präfix für die unterschiedlichen Objekte zu verwenden.

Leider ist das -zumindest bei SQL- nur bis zu einem gewissen Grad möglich, das man imho keine echten Namespacehierarchien("Foo.Bar.Blub.Bla") aufbauen kann. In Delphi geht das, zumindest bei den Unit-Namen()

Aber immerhin: Ordnung ist das halbe Leben.

[mm1256]

Zitat von Rollo62:

Das wäre bei mir:

Code:

KundenFrm.pas
KundenDm.pas
KundenData.pas

Und schon habe ich lesbaeren Code, der sich auch noch sehr gut mit Codevervollständigung verträgt.
Das meinte ich mit "Klassenähnlich".

In der ".dpr" sortiere ich die Uses-Liste generell nach Dateinamen und da hab ich die Formulare, Dialoge und Datenmodule gerne schön beisammen. Das ist mir lieber als bei deiner Variante alle "Kunden-Units" beisammen zu haben.

Aber, das soll jetzt keine Kritik oder Abwertung sein. Wie schon mehrfach angemerkt, alles Geschmacksache. Macht jeder so wie er es gewohnt ist, und für richtig hält.

Zitat von Rollo62:

Manchmal muss es Q&D gehen.

Stimmt. Ich habe aber die Erfahrung gemacht, dass sich Q&D niemals lohnt, denn irgendwann geht einem dieser Q&D-Code auf den Geist und dann ändert man doch ab, und dabei passieren dann gerne Flüchtigkeitsfehler. Zumindest geht (bzw. ging) es mir früher so, und darum hasse ich Q&D wie die Pest. Hat unter'm Strich noch nie was gebracht. Außer im Nachhinein Mehrarbeit, Ärger und Stress.