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

[frankyboy1974]

Hallo,

ich programmiere in Delphi wie in Java, also mit Framework Richtung GUI.
Komponenten haben gar keinen Namen (zumindestens für mich nicht), und schreiben die Eingabe nur in das entsprechende Model. Nachdem ich eine GUI-Komponente auf den Bildschirm gepackt habe, funktioniert diese so wie alle anderen.
Danach kann ich keine GUI-Komponente mit ihrem Namen ansprechen, wenn ich eine implizite Änderung haben möchte, geht dies nur über das Model.

mfg

Frank

[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...

[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).

[Dejan Vu]

Ich finde, wenn ich im Code kodieren muss, woher meine Werte kommen oder wo sie liegen ('L', 'A', 'F'), dann ist mein Implementierung zu kompliziert. Meine Methoden haben maximal 7, in Ausnahmefällen auch mal 10 Zeilen, zuzüglich 1-3 Zeilen Deklaration lokaler Variablen). Da muss ich nichts zusätzlich kodieren: Ich sehe doch auf den ersten Blick, was 'FooBar' für ein Ding ist.

Allerdings geht Konvention und Standard (welcher, ist egal), über alles. Wenn es also üblich ist, die Typen, Interfaces und Felder mit dem entsprechenden Präfix zu versehen, mache ich da mit. Es tut nicht weh und man muss sich nicht ständig erklären.

Was die VCL-Steuerelemente anbelangt, habe ich jahrelang 'ed', 'lb', 'cb' etc. verwendet. Bis ich gemerkt habe, wie überflüssig das ist. Während ich sonst auf Lesbarkeit (Clean Code) allergrößten Wert lege, schlampe ich dafür bei den Control-Namen? "Wie blöd ist das denn?" habe ich mir gedacht. Und wenn ich mir schon überlegen muss, ob welchem Namen ich einem Control verpasse (edName? NameEingabe? NameEdit?) verwende ich vermutlich eh zu viel Logik im UI-Code.

Im Idealfall (Binding), verwende ich die Controls überhaupt nicht im Code. Alles ist in der DFM und da ist es auch wurscht, wie die Controls heißen. Aber klar, manchmal muss man tricksen, aber eigentlich fast ausschließlich in Eventhandlern. Und da kommt das Control in Form eines 'Sender' und kann auf eine klar benannte lokale Variable gecastet werden.

Nur in seltenen Fällen würde ich einem Control einen Namen verpassen. Aber dann ohne erklärenden Prefix (oder Suffix), denn im Namen soll idealerweise die Implementierung *nicht* vorkommen.

Edit: Habe gerade bemerkt, das sich meine Ansichten mit der von Sebastian (Jaenicke) ziemlich genau decken...

[Mavarik]

Zitat von Dejan Vu:

Meine Methoden haben maximal 7, in Ausnahmefällen auch mal 10 Zeilen, zuzüglich 1-3 Zeilen Deklaration lokaler Variablen).

Die Software möchte ich mal sehen... Kann ja nur ein Call nach dem anderen sein...

[Dejan Vu]

Mavarik, lies einfach mal das Buch 'Clean Code' oder schau dir z.B. den Quelltext von z.B. DevExpress an (obwohl die an einigen Stellen mittlerweile Anfänger einsetzen).

Oder stell Jaenicke die gleiche Frage. Offensichtlich bevorzugt er auch lesbaren Code.

[TRomano]

@Dejan Vu: das artet schon wieder in einen akademischen Streit aus ...

Auch ich habe 'Clean Code' gelesen, aber sich auf 10 Zeilen zu beschränken ist auch nicht immer förderlich. Wenn es zum Beispiel um Speed & Optimization (Stichwort unrolled loops) geht, dann geht das nicht mit 10 Zeilen, sondern halt auch mal mit 30-50 Zeilen. Ansonsten sollte man natürlich versuchen die Procs/Funcs kurz zu halten, damit man den Überblick behält. Aber es ist halt auch kein Dogma und man man ist kein schlechter Codierer, wenn man 30 Zeilen Code in einer Prozedur hat !