Bt=Button, Lb=Label, Ed=Edit

[Elvis]

Zitat:

Zitat von Lemmy1

Wenn ich den Typen wirklich angeben MUSS, dann hinten angestellt. So heissen meine Controls z.B.
"NameLabel", "NameEdit", "OKButton". Das hat nebenbei den Vorteil, dass alle Name-Controls in der Intellisense zusammen erscheinen. Muss sich jemand anders den Code anschauen, so muss er außerdem keine Abkürzungen lernen, sondern versteht sofort, um welches Control es sich handelt.

Janz jenau so sieht's aus. :)
Bis auf Controls gibt es keinen Grund den Typ eines Bezeichners in seinem Namen mit hineinzuverschlüsseln. Das sieht nicht nur aus wie der neueste Appetitszügler von Ratiopharm, das liest sich auch so... :roll:
Bei Controls sollte der Grund klar sein, die Viecher benehmen sich einfach oftmals grundverschieden, auch wenn die Eigenschaften und Methoden gleich/ähnlich heißen. Und Controls benutzt man eh nur in GUI Code, so what? ;)
"fileNameTextBox" liest sich doch viel schöner als "trshtbrsthcblaFileName". Mag wohl daran liegen dass es richtige Wörter sind und das Hirn nicht den ungarischen Decrypter anwerfen muss.
Bei Feldern bevorzuge ich ein kleines "f", da es sich nicht so aufdrängt. Bei einem großen "F" muss man eine 20-tel Sekunde länger drauf gucken...

[alzaimar]

Zitat:

Zitat von Mackhack

Zitat:

Zitat von Cöster

Zitat:

Zitat von MaBuSE

Da man nie weiß, ob das Team später international wird, werden von vielen Teams gleich alle Benamungen in Englisch gehalten. Das macht die Sache auch einheitlicher, da die VCL ja auch komplett in Englisch ist.

Sehr interessanter Punkt, über den sich sicherlich auch Streiten ließe. Ich fühle mich nämlich auch immer hin- und hergerissen. Einerseits pro Englisch, Grund hast du ja genannt.
Aber das kann man ja auch anders sehen: Wenn man deutsche Namen nimmt, kann man leichter unterscheiden, was von einem selber kommt und was Delphi einem zur Verfügung stellt. Außerdem kommt es dann seltener zu Namenskonflikten.

Ich finde English in diesem Falle nur aus einem Grund besser. Du kommst in der Regel mit nur einem Wort aus um der Variablen zu sagen was sie tut. Im deutschen geht das oft nicht oder es ist ein irrsinnig langes Wort!

Ich finde es immer wieder amüsant, wie man krampfhaft (mit Wörterbuch oder dict.leo.org versucht), einen sinnvollen englischen Ausdruck für das zu finden, was man ja schon in Deutsch ausgedrückt hat. Natürlich bleibt es jedem selbst überlassen, aber mal im Ernst: Wie viele programmieren wirklich in einem internationalen Team?

Wichtig ist zunächst, das ICH das in einigen Jahren noch verstehe. Dann, das meine Kollegen das verstehen. Neulich las ich im Code eines Mitstreiters etwas von "AppendPosts". Klar, es geht um Posten, nur das 'Posts' Pfosten bedeutet. Stände "PostenHinzufuegen", hätte ich das sofort kapiert. Im leo.org steht unter 'Posten' natürlich auch das 'Post', sodaß der gute Mann einfach meinte, das würde schon hinhauen. Ich als halber Brite hab den Code so lange nicht verstanden, bis ich dann auch mal die darunterliegende DB analyisert habe.

Leute, es geht 1. ums Verständnis, 2. ums Verständnis und 3. darum, das Andere den Code verstehen. Dazu gehören gute Bezeichner (geht auch in Deutsch, man muss nur wollen) und sinnvolle Kommentare. Als beste Technik hat sich bei uns das Code-Review erwiesen. Dabei gleichen sich die Nomenklaturen mit der Zeit automatisch an. Gleichzeitig wird der Code übersichtich, weil man einfach keinen Bock mehr hat, dem Anderen zum 1000.ten mal den eigenen Frickelcode zu erklären.

Die 2-buchstabigen Prefixe für Komponenten verwenden wir auch, obwohl 3 besser wären, die haben sich aber nicht durchgesetzt. Dabei sind alle Eingabefelder 'edXXXX', egal ob es ne Checkbox, ein Edit, MaskEdit etc. ist, es wird also eher informativ und nicht so strikt gehandhabt.

Globale Variablen gibt es nicht. Und wenn, dann sind sie so lang, das man sofort weiss, das es ne Krücke ist. Lokale Variablen haben ein Zeichen, das den Typen angibt, mit der Ausnahme der Zählvariablen i,j,k, Pointern p und q, String s und t, sowie Floats a und b, sowie x und y.
Das mit dem 1-Zeichen-Präfix finde ich eigentlich blöd, aber es ist so übersichtlicher, da Methoden und Properties keinen Präfix besitzen und man so sofort weiss, das 'iValue' eine lokale Variable und 'Value' eine Property/Function ist.

Felder beginnen mit fXXXX, Typen mit 'T', Exception mit 'E'.

Nochwas? Enumerationen beginnen mit 3 Buchstaben, die den Enumerationstyp wiederspiegeln ('TMyEnumerations = (menOne, menTwo...')

Usw usw usw.

Wir machen das so seit 10 Jahren und bisher fahren wir ganz gut damit. Heute fällt eine Prämisse mal weg, dafür kommt dann morgen eine dazu. Ich lass mich gerne inspirieren und bringe neue Ideen in das Team ein. So entwickelt man sich ständig weiter.

[Lemmy1]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Lemmy1

Wenn ich den Typen wirklich angeben MUSS, dann hinten angestellt. So heissen meine Controls z.B.
"NameLabel", "NameEdit", "OKButton". Das hat nebenbei den Vorteil, dass alle Name-Controls in der Intellisense zusammen erscheinen. Muss sich jemand anders den Code anschauen, so muss er außerdem keine Abkürzungen lernen, sondern versteht sofort, um welches Control es sich handelt.

Janz jenau so sieht's aus. :)
Bis auf Controls gibt es keinen Grund den Typ eines Bezeichners in seinem Namen mit hineinzuverschlüsseln. Das sieht nicht nur aus wie der neueste Appetitszügler von Ratiopharm, das liest sich auch so... :roll:
Bei Controls sollte der Grund klar sein, die Viecher benehmen sich einfach oftmals grundverschieden, auch wenn die Eigenschaften und Methoden gleich/ähnlich heißen. Und Controls benutzt man eh nur in GUI Code, so what? ;)
"fileNameTextBox" liest sich doch viel schöner als "trshtbrsthcblaFileName". Mag wohl daran liegen dass es richtige Wörter sind und das Hirn nicht den ungarischen Decrypter anwerfen muss.
Bei Feldern bevorzuge ich ein kleines "f", da es sich nicht so aufdrängt. Bei einem großen "F" muss man eine 20-tel Sekunde länger drauf gucken...

Freut mich ja zu hören, dass ich nicht der einzige bin. Also ich nehm deshalb Großbuchstaben, da Pascal-Casing nach Pascal benannt ist und ich es somit als meine historische Pflicht sehe, dass auch zu verwenden...

Was mir noch eingefallen ist: Präfixe muss man natürlich auch bei Enums nehmen, da Enum-Members ja in Delphi leider kaum mehr als globale Konstanten sind (eine Syntax in der Art "TFileOpenMode.Create" gefällt mir besser als "fomCreate"; nebenbei würde sie vor Namensraumkonflikten schützen).

[Der_Unwissende]

Zitat:

Zitat von Lemmy1

Was mir noch eingefallen ist: Präfixe muss man natürlich auch bei Enums nehmen, da Enum-Members ja in Delphi leider kaum mehr als globale Konstanten sind (eine Syntax in der Art "TFileOpenMode.Create" gefällt mir besser als "fomCreate"; nebenbei würde sie vor Namensraumkonflikten schützen).

Wobei hier natürlich eh die Empfehlung gelten sollte, dass man Konstanten mit dem Namen der Unit aus der sie kommen qualifiziert, das vermeidet auf jeden Fall immer die versehentlichen (und nicht immer zu sehenden) Konflikte

[xZise]

Also ich nehme immer klein Buchstaben, und dann den Anfangsbuchstaben des Wortstamms. (das "T" wird weggelassen)
Ausnahme ist Form => frm ;)

• edit e
• label l
• TreeView tw
• CheckBox cb
• ComboBox cb
• ValueListEditor vle

[MaBuSE]

Zitat:

Zitat von xZise

• CheckBox cb
• ComboBox cb

Und wie unterscheidest Du verschiedene Komponenten mit gleichem Prefix z.B. cb

Damit sind ja die Prefixe sinnlos. Und Du könntest sie auch weglassen, wenn sie kein eindeutiges Unterscheidungsmerkmal sind. ;-)

[_frank_]

Zitat:

Zitat von xZise

• ...
• CheckBox cb
• ComboBox cb
  ...

also kann es sein, dass eine Combobox genauso heist wie eine Checkbox ;)

ich hab mir mittlerweile angewühnt so zu beschriften:

CB_ = ComboBox
Chk_ = Checkbox
Lbl_ = Label
TV_ = Treeview
LV_ =ListView
Btn_ = Button
GrpBox_ = GroupBox
LB_ = ListBox
...

Gruß Frank

[RavenIV]

Also ich habe auch die Erfahrung gemacht, dass Komponenten-Identifizierung sehr wichtig sein kann.

Ich muss hier in der Firma ein Projekt weiterführen, das ich von einem Kollegen übernommen habe.
Es gibt zwar einen Styleguide (angelehnt an den von Borland) bei uns, aber eben dieser Kollege gehört zu den "Faulen" und meint, er sei etwas besseres. Daher heissen die Buttons Button1 bis Button23 und Labels heissen Label1 bis Label34. Da blickt keine Sau mehr durch. Vor allem wenn es dann eine Button7Click und eine Button17Click gibt. Im StyleGuide steht geschrieben, dass die Buttons z.B. BuSpeichern oder BuMachIrgendwas heissen sollen.
Ich würde am liebsten jedesmal wenn ich einen Button3 sehe, zu dem Kollegen laufen und ihm eine runterhauen. Aber dann hätte dieser Kollege lauter blaue Flecken im Gesicht.

Ich bin ja auch nicht der Tipp-Weltmeister, deshalb habe ich CnPack installiert mit dem NamingAssist (oder wie auch immer das Teil heissen mag). Der bringt mir einen Dialog, bei dem der Präfix schon drin steht. Die Präfixe kann man für jede Komponente konfigurieren, ist halt ein Bissle Arbeit.

[xZise]

Ja ich weiß, dass cb mehrdeutig ist, aber das stört mich kaum, weil es bei mir nicht häufig mehrere "cb"s gibt.
Das Problem liegt nachher z.B. Bei den Labeln.

Beispiel:
Man hat 2 Labels untereinander.
im oberen steht z.B. "Name" und im unteren soll der Name stehen.

Aber wie bennent man sie jetzt :mrgreen:
Ich machs da dann immer "lNameLabel" und "lName". Wobei dann "Label" als Suffix heißt, dass es eine art "Bezeichner" oder "Überschrift" ist.

@ Mabuse: sry, dass ich deinen Thread aufgewärmt habe ^^ Aber ich wollte das nochmal mit den Mehrdeutigkeiten klären :mrgreen:
@ Mabuse2: Sie sind nicht 100% Eindeutig aber vielleicht 80-90% ;) Und das reicht. Weil ich finde, Btn oder so kann man benutzten, wenn man nichts ständig "Button" schreiben will :D

[Balu der Bär]

Vor diesem Problem mit dem Labels stehe ich auch grade. Ich habe es so gelöst das ich statischen Labels (dessen Eigenschaften ich nie ändere, z.B. Info-Texte) auch keinen Namen gebe. Da ich diese im Code nie verwende können sie auch Label14 heißen, stört mich ja dann nicht weiter.