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

[Sherlock]

Es gibt da ja im Borland Styleguide edn.embarcadero.com/article/10280 (ja Borland. Da steht zwar irgendwo im Link Embarcadero, aber im weiteren Verlauf wird so oft der Name Borland genannt, daß man vor Rührung heulen möchte) den Abschnitt zur Namenskonvention. Interessanterweise gibt es dort keinen Hinweis auf die Notwendigkeit von Typangaben bei Bezeichnern - weder Prä noch Suff werden da gefordert. Im Prinzip haben die ja sogar Recht, da entwickelt man endlich nicht mehr in einem Texteditor, sondern in einer IDE mit so mächtigen Dingen wie Tooltips, die einem im Nullkommanix den Typ und den Ort der Deklaration anzeigen können, da ist ein wie auch immer gearteter -fix nicht mehr nötig. Nun ist der Mensch aber ein Gewohnheitstier, was früher unter Fortran gut und richtig wahr, ist auch heute noch gültig. Darum bemüht man sich um schöne Bezeichner, die den Typ wiedergeben sollen.

Hier nun zum Kern: Am beliebtesten scheint aktuell der Präfix zu sein. Wenn man also ein TEdit hat, das erlaubt einen Vornamen einzugeben, wird das Ding in der Regel (Abkürzungen machen das Leben leichter) EdVorname genannt. Für ein Label zu eben diesem Edit folgt demnach LblVorname .

Es gibt aber auch die andere Möglichkeit, nämlich den Typen ans Ende zu setzen. Es gäbe dann also ein VornamenEd und ein VornamenLbl (Man beachte die Grammatik).

Meine Präferenz geht klar zu letzterem, wobei ich aber Basistypen wir Integer, String oder Boolean weglasse. Das ist nun wirklich entweder dem sinnvollen Namen oder auch besagtem Tooltip zu entnehmen. Ich würde also nur bei komplexen Objekten ein Typensuffix verwenden. Zusätzlich würde ich den Suffix nicht abkürzen, sondern ausschreiben - bevorzugt jedoch den einfachen Vorfahren (statt BerufsDBLookUpComboBox lieber BerufsCombo ).

Wie haltet Ihr das also mit der Namenskonvention?

Sherlock

[Der schöne Günther]

Meinst du

1. Die Benennung von Komponenten auf VCL/FMX-Formularen
2. Die allgemeine Namensgebung für alle Bezeichner?

Ich bekomme Ausschlag wenn ich sehe wie manche Leute in Pascal ihre Bezeichner dekorieren. Meine Weltanschauung sagt:

• A vor Parametern ("Argument"): NEIN.
• L vor lokalen Variablen: NEIN.
• T vor Typbezeichnern ("TObject"): Ja, denn Pascal ist leider case-insensitiv.
• P vor Pointer-Typen: Ja. Wahrscheinlich C-Angewohnheit, denn dort ist vieles weniger typsicher. In Delphi könnte man sich das wohl in 90% aller Fälle sparen
• I vor Interface-Typen. Ja. In C# ist es auch so, ist glaube ich einfach nur ein Microsoft-Stil. Woanders habe ich so etwas nämlich noch nie gesehen.
• F vor Klassen/Record-Feldern. Jein. Ich hasse es wie die Pest. Hat man aber eine gleichnamige Property geht es nicht anders. Wäre Pascal case-sensitiv würde ich es über Groß/Kleinschreibung machen (Property groß).
• Statische Methoden: Anfangsbuchstabe groß. Instanzmethoden: Anfangsbuchstabe klein. Meine einzige Hilfe- Ich komme bis heute nicht damit zurecht, wie man in Delphi sonst vernünftig erkennen kann ob eine Methode statisch ist oder nicht!

Zu Komponenten auf Formularen: Ich packe den Typen auch immer in den Namen, allerdings am Schluss. Was bringt es wenn er am Anfang steht? Vor allem so komisch abgekürzt? Ich sehe nicht wo ein "btnStartSomething" besser und leserlicher ist als ein "startSomethingButton". Vor allem weil sich jeder für jede Komponente wahrscheinlich eigene Abkürzungen erfindet...

[MichaelT]

a ... ist durchaus nicht ungewöhnlich - ein unbestimmter Artikel oder unbest. Zahlwörter. (a, some, ..)

Das mit dem l hat heute keine Bedeutung mehr. Die Methoden viel kürzer sind als noch vor geraumer Zeit. Der Vorteil ist beim Suchen sieht man die Zuweisungen. Bei prozeduralen Sprachen (PL-SQL oder ABAP) ist das vorteilhaft - Verbundtypen. Bei mir blieb auch nurmehr lWork ... das sind beliebige Verbundtypen außer Klassen eben instanziert, alles was so an 'record' erinnert.

Zitat von Der schöne Günther:

Ich bekomme Ausschlag wenn ich sehe wie manche Leute in Pascal ihre Bezeichner dekorieren. Meine Weltanschauung sagt:
[LIST][*]A vor Parametern ("Argument"): NEIN.[*]L vor lokalen Variablen: NEIN.

[Mavarik]

Zitat von MichaelT:

Das mit dem l hat heute keine Bedeutung mehr. Die Methoden viel kürzer sind als noch vor geraumer Zeit. Der Vorteil ist beim Suchen sieht man die Zuweisungen. Bei prozeduralen Sprachen (PL-SQL oder ABAP) ist das vorteilhaft - Verbundtypen. Bei mir blieb auch nurmehr lWork ... das sind beliebige Verbundtypen außer Klassen eben instanziert, alles was so an 'record' erinnert.

Delphi-Quellcode:

... // Einige Zeilen Source 

LWert := AWert; // Ah OK wurde an die Procedure übergeben und nur lokal gespeichert...
FWert := AWert; // Ah OK wurde an die Procedure übergeben und wird in der Klasse / Im Record gespeichert

Nummer := Wert; // sagt überhaupt nix aus

if IWert <> NIL then // Muss ein Interface sein...

PSource := AText; // Auch klar

Also sehr sinnvoll...

[Sir Rufo]

Ich verwende immer den Typen als Suffix.

Delphi-Quellcode:

KundeIdLabel: TLabel;
KundeNummerEdit: TEdit;
KundeNameEdit: TEdit;
LieferantIdLabel: TLabel;
LieferantNummerEdit: TEdit;
KundeEditForm: TForm;

Meine Denkweise ist eben einfach so, dass ich z.B. vom Lieferent die Nummer irgendwo hinschreiben möchte und dann sehe ich duch CC sofort, aha ein Edit/Label.

• LieferantNummerEdit
• LieferantNummerEdit
• LieferantNummerEdit

Und weil der Typ am Ende steht, habe ich auch sofort die Assoziation zum Typen und weiß, was ich dort an Eigenschaften und Methoden erwarten kann.

[Luckie]

Ich bevorzuge Präfixen. Und der Typ ergibt sich aus der Benennung:

PersonalNummer -> Integer
PersonalName -> String
IstKrank -> Boolean

Und bei den heutigen modernen IDs mit Codevervollständigung machen Typen in der Benennung den Code nur unübersichtlicher. In den 70'ern mit C und typenunsicheren Sprachen war es wohl mal sinnvoll. heute sehe ich keine Notwendigkeit dazu. Und du hast ja selbst gesagt, dass da immer der Name Borland auftaucht, da kannst du schon sehen, wie alt das Dokument ist.

[p80286]

Zitat von Luckie:

Ich bevorzuge Präfixen. Und der Typ ergibt sich aus der Benennung:

PersonalNummer -> Integer
PersonalName -> String
IstKrank -> Boolean

ist dieser Blödsinn, denn nicht auszurotten?
Die Personalnummer ist nicht numerisch! Es ist eine Aneinanderreihung von Ziffern, damit wird nicht gerechnet, und führende Nullen gehören dazu!
(vllt. wäre es besser von Personalkennung zu reden)
Immer wieder schön wenn Excel Personalnummern als numerische Werte sortiert, und dann jemand aufgeregt über die Flure läuft "der X ist nicht mehr bei uns!"

Gruß
K-H

[Daniel]

Ich denke, dass es Michael um die Namensgebung ging.
Eine Variable endet bei ihm auf "Nummer" und ist folglich numerisch, endet sie auf "Name" kann man einen String vermuten und Dinge, die mit "Ist" beginnen, scheinen boolsche Flags zu sein.

Um den Aufbau von Personalnummern und deren Behandlung ging es Michael mutmaßlich nicht.

[mquadrat]

Bei der Personalnummer finde ich es nicht so schlimm (bei einigen Firmen sind die Dinger tatsächlich numerisch [also ohne führende Nullen]). PLZ als integer ist viel lustiger

Zum Thema:
Komponenten werden gepräfixt, weil war schon immer so. Bei Forms, die per Convention over Configuration automatisch gebunden werden, haben dann natürlich kein Präfixe bei den Komponenten. Private Attribute in den Klassen kriegen bei uns einen _ statt einem f. Haben wir auch mal von irgendwo übernommen.

[jaenicke]

Zitat von Der schöne Günther:

Zu Komponenten auf Formularen: Ich packe den Typen auch immer in den Namen, allerdings am Schluss. Was bringt es wenn er am Anfang steht? Vor allem so komisch abgekürzt? Ich sehe nicht wo ein "btnStartSomething" besser und leserlicher ist als ein "startSomethingButton". Vor allem weil sich jeder für jede Komponente wahrscheinlich eigene Abkürzungen erfindet...

Schlicht weil es so sehr viel einfacher ist eine bestimmte Komponente anzusprechen. Wenn ich ein Label suche, schreibe ich lbl, und in der Regel finde ich es dann über die Syntaxergänzung direkt über den Namen ohne auf das Formular schauen zu müssen.

Außerdem gibt es dann ein lblItemName und ein edtItemName, d.h. die Beschriftungslabels können abgesehen vom Typ genauso heißen.
Bei Variablen macht die ungarische Notation in Delphi aber keinen Sinn.

Ansonsten mache ich es etwas anders als du:

• A vor Parametern ("Argument"): Ja, denn so können diese genauso wie Properties der Klasse heißen ohne dass der Name exakt gleich ist.
• L vor lokalen Variablen: Nein, denn wer so lange Methoden hat, dass man das braucht, der hat ganz andere Probleme...
• F vor Klassen/Record-Feldern: Mache ich immer so, denn abgesehen davon, dass es Konvention ist, ist es sehr praktisch für die Übersicht. Und ich kann immer ein F schreiben und bekomme alle privaten Felder. Denn nur dort gehört das F hin, nicht vor alle Felder.

Zitat von Der schöne Günther:

P vor Pointer-Typen: Ja. Wahrscheinlich C-Angewohnheit, denn dort ist vieles weniger typsicher. In Delphi könnte man sich das wohl in 90% aller Fälle sparen

Naja, es ist schon praktisch, wenn ich einen Typ TExample habe, dazu einen Pointertyp PExample und eine Variable Example.
Sich da jedesmal krampfhaft etwas auszudenken hielte ich für deutlich weniger schön.

Zitat von Der schöne Günther:

Statische Methoden: Anfangsbuchstabe groß. Instanzmethoden: Anfangsbuchstabe klein. Meine einzige Hilfe- Ich komme bis heute nicht damit zurecht, wie man in Delphi sonst vernünftig erkennen kann ob eine Methode statisch ist oder nicht!

Für solche Sachen gibt es ja den Code Explorer, das sieht man dort glaube ich auch sofort:
http://www.modelmakertools.com/code-explorer/index.html

Zitat von Der schöne Günther:

Ich bekomme Ausschlag wenn ich sehe wie manche Leute in Pascal ihre Bezeichner dekorieren.

Ich halte mich an den Styleguide und an die Konventionen. Das finde ich besser als sich eigene Regeln auszudenken, die dann von jedem fremden Quelltext abweichen (z.B. eben, wenn du kein F vor privaten Felder nutzt).