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

[Captnemo]

Da ich mir das CN-Pack installiert habe, werden bei Komponenten auf der Form diese gleich automatisch umbenannt.
Checkbox -> chkBlablabla
Edit -> edtBLablabla
Listbox -> lstBlablabla

Der Vorteil: in der CodeCompletition kann ich chk schon mal auf alle Checkboxen einschränken. Der Datentyp ist dabei ja auch schon irgendwie klar.

Diese Schreibweise ist bei mir dann irgendwann mal in Fleisch und Blut übergegangen.

Ansonsten
Klassen TBlabla
Pointer PBlabla
Klassenvariablen FBlaBla

Das voranstellen des Datentyps mache ich nur in lokalen Verablen iBlabla für Integer, sBlabla für String, usw.

Ansonsten verwende ich nach Möglichkeit Namen, die die Funktion oder den Inhalt dahinter möglichst klar benennen z.B. Function GetIndexOfPhonenummer(...)

Alles andere hole ich mir über die Möglichkeiten, die mir die IDE zur Verfügung stellt, wenn ich weitere Info's brauche.
Solange ich den Code für mich schreibe, komme ich damit sehr gut klar, auch nach Jahren.

[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