Ein ewiger Streitpunkt von Entwicklern ist das Benennen von Variablen, Funktionen, Klassen und Co. Am Anfang ist immer eine gerade Linie drin, aber irgendwann kommen neue Teammitglieder hinzu, die die Regeln zum Benennen nicht ganz so ernst sehen. Und auch die alten Hasen leiden ab und zu an Vergesslichkeit.
Aus heiterem Himmel ist es dann eine riesen Herausforderung, wenn man sich auf Quellcode konzentrieren muss und nur noch KamelArtige variablen_benennungen bunt vermischt mit _großUndKlein geschriebenen Deklarationen und Aufrufen vor sich sieht.
Um Diskussionen vorzubeugen ist eine schriftliche Konvention zum Codestyle anzuraten. Für was man sich nun letzten Endes entscheidet, ist eigentlich egal und Geschmackssache. Nur einheitlich sollte es sein.
Schauen wir uns mal an, was die Bennungspalette so bietet.
Wahrscheinlich vergesse ich eine Variante, aber dafür gibts ja die Kommentarfunktion ;)
Die Grundsatz-Regelungen:
Die erste Hauptregel sollte sein: Bennene die Variable nach dem Inhalt. Die zweite: Bitte keine Abkürzungen - und wenn: Nur gebräuchliche…
Gebräuchlich im Sinne von bekannt und verbreitet ist z.B. ”db” für …………..genau: “Datenbank” (oder “Database”; sogar mit internationaler Gültigkeit), da weiß man was man hat. Ein Kollege wollte im Team verzweifelt “DaBa” als Datenbank-abkürzung einführen. Vergeblich. Das erinnert eher an einen afrikanischen Vornamen und verwirrt eher ;-)
Die zweite Regel: Welcher Sprache möchte man sich bedienen? Die Landessprache (hier wäre das deutsch, das vergisst man manchmal ;) oder lieber englisch-international. Man sollte sich für die internationale Variante entscheiden, wenn man das Projekte offen sourcen möchte (Stichwort “Open Source”).
Aber Vorsicht! Lieber das eine oder andere Mal LEO benutzen, und so gravierende Übersetzungsfehler vermeiden. In einem Projekt, zu dem ich vor ein paar Jahren gestossen bin, wurde der Parameter für die aktuelle “Seite” mit “Site” übersetzt. Upps. “Page” wäre wohl besser gewesen, na das kann ja peinlich werden.
Man hat sich also einen Bezeichner überlegt. Nehmen wir mal “Datenbank-Abfrage-Objekt”, das ist umständlich und taugt nur als Beispiel, weils ein langer Bezeichner ist. Übrigens: Einer meiner Lieblingslehrer hat mal gesagt “Keine Angst vor großen Tieren” - ob er da jetzt Elefanten, große Zahlen oder extrem lange Variablenbezeichner gemeint hat - ich habe keine Ahnung. Auf jeden Fall: Lange Variablennamen beissen nicht; im Gegenteil: in einem halben Jahr weiß man noch, was die Variable nun beinhaltet…
So, aber jetzt gehts wirklich los. Wie formatieren wir jetzt “Datenbank-Abfrage-Objekt”, denn der Bindestrich fällt aus? Und das gäbe es zur Auswahl:
- DatenbankAbfrageObjekt (ohne Unterstriche - CamelCase, großer Buchstabe vorne)
- datenbankAbfrageObjekt (wieder CamelCase, diesmal kleiner Buchstabe vorne
- datenbank_abfrage_objekt (Alles in Kleinbuchstaben, Unterstrich als Trenner)
- Datenbank_Abfrage_Objekt (Kapitälchen, wieder Unterstrich als Trenner)
- datenbankabfrageobjekt (Alles in Kleinbuchstaben, gar kein Trenner)
- datenbankABFRAGEobjekt (auch schon gesehen, abwechselnd Groß- und Kleinschreibung bei jedem neuen Wort)
Zu all den Möglichkeiten sollte man auch bestimmen, was man mit Abkürzungen macht. Werden die auch formatiert? Wird aus “DB” vielleicht “db”? Oder doch “Db”? “MySql”, “mysql, “mySql”, MySQL” oder “mySQL”?
Geschmackssache, aber man sollte sich auf eine Regel einigen.
Nun das nächste Thema: Datentypen. Muss das im Namen dargestellt werden? Ich bin der Meinung: Nein. Wenn ein Bezeichner wirklich aussagekräftig ist, muss man nicht. Aber auch hier sollte eine klare Linie beibehalten werden.
Die Verfechter dieser Kennzeichnung setzen meist eine Abkürzung des Datentyps in Kleinbuchstaben vor den tatsächlichen Namen:
- “str” oder “s” für “String” bzw. Zeichenkette
- “int” oder “i” für “Integer” bzw. Ganzzahl
- “float” oder “f” für “Float” bzw. Gleitkommazahl
- “arr” oder “a” für “Array” bzw. Feld
- “obj” oder “o” für “Object” bzw. Objekt
Dann würden etwa folgende Konstrukte entstehen:
- objDatenbankAbfrageObjekt
- obj_datenbank_abfrage_objekt
- obj_datenbankabfrageobjekt
Wer pfiffige ist, hats schon gemerkt: Jetzt haben wir im Namen einen Doppler drin. Ob das so gut ist?
Und wie siehts jetzt mit privaten Klassenvariablen oder sogenannten Member-Attributen aus? Wer das gerne machen möchte stellt meistens entweder ein “m”, einen “_” (Unterstrich) oder beides “m_” davor. Hm, mal schauen:
- m_objDatenbankAbfrageObjekt
- mObjDatenbankAbfrageObjekt
- _objDatenbankAbfrageObjekt
- m_obj_datenbank_abfrage_objekt
- _obj_datenbank_abfrage_objekt
- m_obj_datenbankabfrageobjekt
- _obj_datenbankabfrageobjekt
oder eben ohne Datentyp:
- m_DatenbankAbfrageObjekt
- mDatenbankAbfrageObjekt
- _DatenbankAbfrageObjekt
- m_datenbank_abfrage_objekt
- _datenbank_abfrage_objekt
- m_datenbankabfrageobjekt
- _datenbankabfrageobjekt
Und zu guter Letzt: Konstanten… Hier haben sich Grossbuchstaben mit Unterstrichen als Trenner etabliert. Ist meiner Meinung nach auch das Vernünftigste; so z.B.: “DEFAULT_VALUE”.
Au Backe :( Man kann jetzt erkennen, weshalb das immer wieder ein Streitpunkt ist. Man gewöhnt sich als Entwickler an “seine” Schreibweise und *bums* kommt man in ein Projekt, wo es genau anders herum gehalten wird. Da ist Konzentration angesagt.
Zum Schluss noch das Unwichtigste: Wie hält es der PHP Blogger?
- Nicht-Objekt-Variablen: “position_x”
- Listen/Arrays: “positions_arr”
- Objekt-Variablen: “koordinatenRaster”
- Private Member-Variablen: “_position_x”
- Konstanten: “DEFAULT_POSITION_X”
Die meisten Projekte sind übrigens durchgängig mit englischen Bezeichnern ausgestattet…
Update: Weiterlesen, wenn es um Leerzeichen, Tabs und Absätze geht.
