Access-Namenskonventionen

Autor: Ing. Ernst Greiner

Namenskonventionen sind Regeln
   welche festlegen, wie Objekte, Variablen, Konstanten usw. benannt werden.

Warum Namenskonventionen?

• Ihre Programme werden lesbarer und übersichtlicher, nicht nur für sie, sondern auch für eine größere Entwicklergemeinde.
• Der geringe Aufwand, ordentliche Namen zu geben, steht einem großen Nutzen gegenüber.

Speziell in größeren Projekten verliert man ohne vernünftige Benennungen schnell die Übersicht. Access bietet in dieser Hinsicht auch keine anderen architektonischen Möglichkeiten als über Objektnamen die Software zu strukturieren.

Beispiel, gruppieren sie Abfragen nach ihrer Funktionalität/Zugehörigkeit:

Vergeben sie allen Abfragen die als Datenquelle für Unterformulare dienen das Präfix qfsub.
Alle diese Abfragen sind dann im Datenbankfenster zusammenhängend aufgereiht, sie müssen dann nur mehr in dieser Gruppe alphabetisch suchen. So suchen sie anstatt unter 200 Abfragen nur unter 40, dass spart Zeit und Energie.

Wie gehe ich am besten vor?

• Diese Konventionen sind als Vorschlag gedacht. Wenn sie ihnen nicht gefallen, entwickeln sie ihre eigenen.
• Erweitern sie Ihre Konventionen nach Bedarf, halten sie sich an ein Grundschema.
• Keep it simple - erfinden sie keine komplizierten Abkürzungen.
  Sollte es doch notwendig sein, führen sie in einem eigenen Modul (_Description) eine erklärenden Legende ein
  z.B.: fdlstg ... Dienstleistungsformular.
• Verwenden sie für Bezeichner englische Ausdrücke.
  Englisch verbindet die Nationen der Erde, im Besonderen die Softwerker.

Grundsätzliches

• Verwenden sie nur Buchstaben, die auch im englischen Alphabet existieren, d. h. keine Umlaute, kein ß.
• Keine Sonderzeichen, ausgenommen underscore _ und das sparsam.
• Keine Bindestriche: - diese können als Minus interpretiert werden.
• Keine Leerzeichen.
• Keine reservierten Namen, am "beliebtesten" dabei ist Name.
• Keine Zahlen am Anfang eines Variablen-, Funktionsnamens.

Diese Grundregeln räumen von vornherein einige Fehlerquellen aus.

Sonderzeichen in Namen, dazu gehören Umlaute, ß, Bindestriche usw. führen an bestimmten Stellen der Software zu Komplikationen die nicht sein müssen, deswegen lässt man sie von vornherein weg.

Der Underscore _

Früher wurde der underscore _ exzessiv eingesetzt.
Meiner Meinung nach zerstückelt der underscore einen Objektnamen anstatt ihn zu strukturieren.
Selten ist der underscore wirklich notwendig, verwenden sie stattdessen die Groß-/Kleinschreibung um Objektnamen zu strukturieren, dass liest sich auch flüssiger.

Ich verwende den underscore hauptsächlich dazu, um Testabfragen die anschließend wieder gelöscht werden können ganz am Anfang des Datenbankfensters zu positionieren, das erspart Zeit beim Suchen (_qaddCustomers).
Oder, um übergeordnete Module oder Formulare (_Description, _Todo) wiederum leichter zu finden.

Donts

Feldnamen in Tabellen:
 Straße-Nr
 Straße_Nr
 Straße Nr

Kein Mensch würde auf die Idee kommen eine Variable Straße-Nr zu nennen, der Compiler würde das vermutlich ohnehin nicht zulassen. Es ist hier offensichtlich, dass diese Variable als Straße minus Nr interpretiert wird.
Bei Feldnamen ist diese Unart leider alltäglich.

Does

Es gibt genug bessere Möglichkeiten:
 dtStrasseNr
 dtStrasse
 dtStreetNo
 dtStreet
 StrasseNr
 StreetNo

Access-Objekte

Eine grundsätzliche Unterscheidung von Objekten bringt folgenden Vorteil:

• Tabellen und Abfragen sind eindeutig unterscheidbar.
  Access verarbeitet in einigen Fällen Tabellen und Abfragen als gleichwertig, zum Beispiel bei Datenquellen in Formularen.
• Ähnliches gilt für Formulare und Berichte.
• Bei Makros kann dieses System nicht hundertprozentig eingehalten werden, siehe dazu Kapitel Makros.

Allgemein üblich sind: tab, qry, frm, rpt, mac, mod, und cls welche die Lesbarkeit aber nur unwesentlich erhöhen.
Wichtiger ist meiner Meinung nach die Strukturierung innerhalb der einzelnen Objektgruppen, siehe dazu die nächsten Abschnitte.

Tabellen

Der Vorteil der Strukturierung innerhalb der Objektgruppe ergibt sich einfach daraus, dass bei der Suche nach einem bestimmten Objekt nicht immer der ganze Pool durchsucht werden muss.
Man braucht sich beim Entwickeln nur auf einen bestimmten Abschnitt konzentrieren, was, wie weiter oben schon erwähnt, Zeit und Energie spart.

Dieses Prinzip gilt auch für die folgenden Abschnitte.

Tabellen Feldbezeichnungen

Abfragen

Abfrage Feldbezeichnungen

Grundsätzlich können die gleichen Bezeichnungen wie bei Tabellenfelder verwendet werden.

Formulare

Formular Elemente

Grundsätzlich können die gleichen Bezeichnungen wie bei Tabellen-/Abfragefelder verwendet werden.

Makros

Auf Makros sollte man besser verzichten:

• Makros erlauben keine Fehlerbehandlung
• Makros können nicht debuggt werden
• Makros sind unflexibel und unübersichtlich
• Makros sind in MDE-Dateien ungeschützt

Wenige Gründe sprechen für den Einsatz von Makros:

• Das 'AUTOEXEC' Makro: dieses Makro wird ausgeführt wenn sie eine Datenbank öffnen. Die einzige Aktion die sie in diesem Makro aufrufen sollten, ist das Starten einer VBA-Funktion.
• Das 'AUTOKEYS' (oder 'Tastaturbelegung') Makro überprüft, ob Tasten gedrückt wurden, auf die dann reagiert werden kann.
  Folgende Tasten werden überwacht:
  • Die Funktionstasten F1 bis F12 (+STRG + SHIFT)
  • Alle alphanumerischen Tasten (+STRG)
  • Einfügen und Entfernen-Taste (+STRG + SHIFT)
• Makros können einfach in VBA-Code umgeformt werden. Für Neulinge ist das ein möglicher Einstiegspunkt in die VBA-Welt.

Module

Variablen und Konstanten

Grundsätzlich sollte man Variablen und Konstanten auf einen Blick voneinander unterscheiden können.
Der Grund ist einfach, einer Variablen können sie ständig neue Werte zuweisen, Konstanten weisen sie nur einmal einen Wert zu.

Allgemein wird empfohlen Konstanten groß und Variablen klein zu schreiben.
Um das Programm lesbarer zu gestalten empfiehlt sich Konstanten mit einem großgeschriebenen Teil zu beginnen und Variablen zumindest mit einem kleingeschriebenen Buchstaben zu beginnen.

Beispiel: