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

[Daniel]

Meine Vermutung der fehlenden Reife wird regelmäßig auf's Neue untermauert, da kann ich nichts dafür.
Und es ist genau die perfide Diskussionshaltung, die ich Dir vorwerfe: In einem Satz spricht Du Deinem Gegenüber offen die Kompetenz ab, um dann im (oben erwähnten) zweiten Satz, nonchalant von einem "durchaus guten Entwickler" zu sprechen. Und das soll ich Dir jetzt zu Deinen Gunsten auslegen?
Es ist Deine Art zu diskutieren, deretwegen Du auch schon einmal aus dem Forum geflogen bist. Aber es ist schön, dass der Wunsch, zum Thema zurück zu finden, nun auch von Dir geäußert wird.

[mm1256]

Hallo,

nachdem ich alle Beiträge durchgelesen und dabei auch einige Anregungen gefunden habe, hier mal mein Senf zu diesem Thema. Weil es unterschiedliche Ansichten gab, was der TE grundsätzlich wollte, z.B. Daniel in #14, schlage ich mal rundum:

A vor Parametern ("Argument"): Ja
T vor Typbezeichnern ("TMyClass"): Ja
P vor Pointer-Typen: Ja
I vor Interface-Typen: Ja
F vor Klassen/Record-Feldern: Ja

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 Laufzeit) ist zusammengesetzt aus dem Unit-Namen und einem "_Show", also "Main_Kunden_Show" bzw. "Dlg_Kunden_Show".

Namensgebung bei Komponenten mit 2-stelligem Präfix
cb ComboBox
ck CheckBox
lb Label
lv ListView
ed TEdit . . . usw.
gefolgt vom Variablen-Bezeichner
z.B. eine CheckBox ändert die FormVariable "FUserIsLocked" dann cbFUserIsLocked oder eine TDBCheckBox für das Datenfeld "NUMMER" heißt dann eben cbNUMMER.

Mein wichtigstes Argument für Präfixe - deren Vorliebe ich aufgrund der bisherigen Antworten anscheinend nur mit dem Kollegen "bernau" aus #10 teile:

Zitat:

Ich mag es, wenn ich in der Klasse sortieren kann und alle Edits beisammen habe

Es ist einfach sehr praktisch beim späteren Lesen des Quellcodes, wenn alle Formular-Events schön beieinander sind, und das erledigt dann die IDE so nebenbei automatisch wie gewünscht. Zu dem Thema hat es ja schon einige Diskussionen gegeben.

[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