Namenskonvention (Datenverarbeitung)

Namenskonventionen sind Festlegungen/Vorschriften/Empfehlungen für Programmierer, Datenbankentwickler etc. zur Benennung von Bezeichnern (Namen) für Objekte im Quelltext von Software. Durch ihre Anwendung sollen die Namen dieser Objekte – im Rahmen der Syntaxbestimmungen der Programmiersprache und auch programm-übergreifend – nach einheitlichen Regeln gebildet werden, wodurch das Software-Qualitätsmerkmal Änderbarkeit (Wartbarkeit) durch einfacheres Verstehen des Programmtextes unterstützt wird.

Derartige Regelungen gelten – meist unternehmens- oder projektspezifisch – grundsätzlich für alle in der Programmierung verwendeten Konstrukte – wie Datenfelder (Variablen, Konstanten), Objekte,[1] Funktionen, Typen, Klassen, Module, Prozeduren, Befehlstextabschnitte etc. und sollen zu „lesbarem Code“ beitragen.[2]

Ähnliche Konventionen (sie werden fast immer mit dem Plural bezeichnet) gibt es zum Einrückungsstil und zum Einfügen von Kommentaren in den Quelltext von Programmen.

Namenskonventionen sind strukturell/methodisch ein Teil der Programmierrichtlinien und bestimmen u. a. den Programmierstil für den Programmcode. Sie können je nach Situation/Unternehmen verbindlich vorgegeben oder zur freiwilligen Anwendung formuliert sein.

Beispiele

Ungarische Notation

In der Microsoft-Welt war früher die sogenannte ungarische Notation gebräuchlich, bei der aus dem Anfang eines Bezeichners auf seinen Typ oder seinen Verwendungszweck geschlossen werden kann. Mittlerweile verbietet es Microsoft allerdings die ungarische Notation zu verwenden.[3] Stattdessen sollen Variablen nach Clean-Code-Richtlinien benannt werden.

Kodierung des Typs im Namen

Aus der Programmierung für ganze Zahlen, Gleitkommazahlen, Sonderformate und Zeichenketten:

  • bytZaehler für eine Zähler-Variable vom Typ byte (bis zur Größe 255),
  • intZaehler für eine Zähler-Variable vom Typ integer (von −32768 bis +32767),
  • lngZaehler für eine Zähler-Variable vom Typ long (>32767),
  • sngQuotient für das Gleitkommaergebnis einer Division vom Typ Single,
  • dblQuotient für das Gleitkommaergebnis einer Division vom Typ Double,
  • curNetto für Währungsbeträge vom Typ Currency,
  • strVorname für alphanumerische Zeichenketten vom Typ String

Kodierung der Verwendung im Namen

Für Objekte (hier: relationale Datenbank):

  • tblKunde für eine Tabelle (engl. table), die Kundenstammdaten enthält,
  • qryPLZ4 für eine Abfrage (engl. query), die alle Kunden aus dem Postleitzahlengebiet 40000 bis 49999 zusammenstellt,
  • frmAuftrag für ein Formular (engl. form), in dem Kundenaufträge erfasst/anzeigt/geändert/gelöscht werden können,
  • repUms2005-12_Knd1010 für einen Bericht (engl. report), in dem alle Umsätze des Kunden mit der Kundennummer 1010 aufgeführt sind, die im Dezember 2005 getätigt wurden.

Konstanten in C

In der Programmiersprache C und anderen Teilen der Unix-Welt ist es üblich, Konstanten in Großbuchstaben zu deklarieren (z. B. sngUMSATZSTEUER_ERMAESSIGT für den ermäßigten Umsatzsteuersatz) – insbesondere bei Präprozessor-Makroparametern.

Namenskonventionen für Java

Die Programmierrichtlinien für die Programmiersprache Java legen Namenskonventionen für verschiedene sprachliche Elemente fest, unabhängig von deren Verwendung.[4] Grundsätzlich sollen Java-Bezeichner mit Binnenmajuskeln geschrieben werden (auch Kamelhöcker-Notation, engl. CamelCase genannt) und keine Unterstriche („_“) enthalten, mit Ausnahme von Konstanten (siehe unten).

  • Klassennamen sollen Substantive sein und mit einem Großbuchstaben beginnen, z. B. String oder ArrayList.
  • Methodennamen sollen Verben sein und mit einem Kleinbuchstaben beginnen, z. B. add oder remove. Speziell Abfragemethoden weichen von dieser Regel oft insofern ab, als sie keine Verben sind, und heißen stattdessen beispielsweise toString oder isEmpty.
  • Konstantennamen sollen ausschließlich in Großbuchstaben geschrieben werden, wobei die Einzelworte durch Unterstriche getrennt werden, z. B. MIN_VALUE.

Reddick-Namenskonventionen

Eine Anleitung zur Namensgebung von Variablen, als Variante davon als „Leszynski-Namenskonvention“ (LNC) i. W. für den Einsatz unter Microsoft Access und Visual Basic for Applications angewendet.

Weitere Namensregeln

Weitere, oft nur als Empfehlung gedachte Vorgaben oder Empfehlungen zur Benennung von Objekten im Quelltext können sein:

Sprechende Objektbezeichner

Für Konstrukte, die in der Programmierung über Bezeichner angesprochen werden, kann durch Namenskonventionen festgelegt werden, dass diese weitgehend „sprechend“ gewählt werden. Damit sollen die Bezeichner (im Kontext des Programm-Umfelds) mehr oder weniger „selbsterklärend“ sein, um so auch nicht an der Erstentwicklung des Programms beteiligten Personen die semantische Bedeutung und die Verwendung der Elemente aufzuzeigen.

Ergänzend und präzisierend zu rein umgangssprachlichen Bezeichnern (wie „Rechnungsbetrag“) kann beispielsweise festgelegt werden, ob die Bezeichner aus mehreren Teilen (z. B. zur Unterscheidung von Objekten in unterschiedlichen Rollen) bestehen können/sollen, ob Formatangaben in der Objektbezeichnung enthalten sein sollen, in welcher Reihenfolge Namensteile anzuordnen sind, ob einzelne Bestandteile des Bezeichners z. B. mit Binde- oder Unterstrich oder getrennt werden, ob Abkürzungen zu verwenden sind.

Beispiel mit Gegenbeispiel: MWSt_Betrag = Rechn_Betrag_Nto * MWSt_Prozent anstatt Betrag1 = Betrag2 * Prozent

In der Frühzeit der Datenverarbeitung – z. B. durch Programmiersprachen oder die Verwendung von Lochkarten – existierende Einschränkungen in der Länge von Bezeichnern sind bei den heutigen Systemen üblicherweise nicht mehr relevant.

Weitere Konzepte zur Benennung

In der Programmierung ist es üblich, mit sprechenden Namen neben dem funktionalen Sinn in der Anwendung (der semantischen Bedeutung) mehrere weitere (voneinander relativ unabhängige) Eigenschaften der Elemente zu kennzeichnen, wofür sich einige gebräuchliche Konzepte von Präfixen/Suffixen im Bezeichner herausgebildet haben:

Siehe auch

Einzelnachweise

  1. ↑ Datenbanken verstehen Namenskonventionen
  2. ↑ Uni Tübingen Softwareengineering Best Practises Lesbaren Code schreiben
  3. ↑ Naming Guidelines. In: MSDN. Microsoft, abgerufen am 30. Juli 2014 (englisch).
  4. ↑ Naming Conventions. Oracle, abgerufen am 30. Juli 2014 (englisch, Namenskonventionen für die Programmiersprache Java).