Access VBA – Guter VBA Code

Problem

VBA Code zu schreiben ist einfach, aber guten VBA Code zu schreiben ist schwierig. Was zeichnet nun einen „guten“ VBA Code aus ? Das Programm muß laufen (Keine Bugs), das Programm muß dokumentiert sein, das Programm muß schnell sein.

Lösung

Es versteht sich von selbst, dass man über die folgenden Regeln trefflich diskutieren kann.

Hier nun 17 Regeln zum Erstellen „guten“ VBA Codes

1. Verwende Option Explicit

Die Function Explicit legt fest, daß alle Variablen vor der Benutzung dimensioniert werden müssen. Das verhindert das „Verschreiben“ bei der Benutzung der Variablen.

2. Deklariere die Variablen korrekt

Jede Variable sollte in einer einzelnen Zeile deklariert werden. Dadurch verhindern wir, daß durch falsche Deklaration eine Variant Variable entsteht.
Dim a, b, c as String
In diesem Beispiel ist nur c as String, a und b jedoch als Vairant deklariert.
Dim a as String
Dim as String
Dim ca String

3. Vermeide Variant Variablen

Variant Variablen schlucken alles, sie geben daher keine Fehlermeldung, wenn zum Beispiel ein nicht korrektes Datum in die Vairable gesetzt wird. Variant ist langsam und können unerwartete Ergebnisse bringen da keine Plausibilitätskontrollen erfolgen.

4. Verwende keine Typkennzeichen

Viele Variablen haben so genannte Typkennzeichen, so kann eine Variable als String definiert werden, indem das $ Zeichen als String Typkennzeichen verwendet wird :
Dim Nachname$
Diese Art der Deklaration ist veraltet und nur aus Gründen der Abwärtskompatibilität noch vorhanden. Nicht alle Variablentypen haben ein solches Kennzeichen.

5. Achte auf die Reichweite Deiner Variablen

Eine als Public deklarierte Variant Variable kann von jedem Modul der Datenbank aus genutzt werden, aber ist dies auch notwendig ? Im Gegensatz dazu hat eine als privat deklarierte Funktion ihren Gültigkeitsbereich nur innerhalb der Prozedur. Variablen mit zu großer Reichweite erschweren das Finden von Fehlern.

6. Konvertiere Daten Typen explizit

Wenn wir die Daten aus einer Variable in eine andere packen, so wird bei unterschiedlicher Variablenart eine automatische Konvertierung vorgenommen. Das kann zu unerwünschten Ergebnissen führen. Wenn also aus einer Double Zahl eine Integer Zahl werden soll, so verwenden die Konvertierungsfunktion CInt() und packe die Fließkommazahl Zahl nicht einfach in eine entsprechende Int Variable.

7. Deklariere den Rückgabewert einer Funktion

Genau wie bei den Variablen sollte auch der Rückgabewert einer Funktion deklariert werden, andernfalls gibt die Funktion einen Varianttyp zurück. Es bestehen die gleichen Probleme wie bei der mangelden Deklaration von Variablen

8. Verwende eine robuste Fehlerabfangroutine

Jede Funktion und sei sie noch so klein, sollte eine Fehlerroutine haben. Dabei empfielt es sich, den Original Fehler zu protokollieren und den Anwender mit einer „schönen“ Fehlermeldung zu verwöhnen.

9. Lege Wert auf die Kontrolle Deines Programms

Sprungmöglicheiten wie GoTo oder GoSub kommen aus der guten alten Zeit des BASIC. Dies hat nichts mehr mit der modularen Programmierung unter VBA zu tun.
Wähle das GoTo nur für die Fehlerroutine und schaffe nicht mehrere Möglichkeiten den Code zu verlassen (Exit Sub oder Exit Function). Unbehandelte Fehler und nicht geschlossene Objekte könnten sonst die Folge sein.

10. Nutze Variablen anstelle von Konstanten

Versuche es zu vermeiden, feste Konstanten in dem Code zu verwenden, sonst verstehst Du Deinen eigenen Code nach kurzer Zeit nicht mehr
Kindergeld = vKinderzahl * 150
Was soll die 150 darstellen ??
Benutze Variablen
vKindergeldsatz = 150
Kindergeld = vKinderzahl * vKindergeldsatz
Ein weiteres Problem dieser Konstanten ist, daß bei einer Änderung die Konstante mehrfach im Code auftauchen kann und es damit sehr schwer ist, sie zu ändern. Im Fall einer Variablen ist es nur an einer Stelle zu ändern.

11. Benutze Namenskonventionen

Bei der Benennung von Variablen solltest Du sinnvolle Namen nutzen. Ähnlich wie bei den Access Objekten, kannst Du zum Beispiel alle String Variablen mit einem str am Anfang setzen um den Typ der Variablen zu definieren. Schaffe die Unterscheidungsmerkmale für die Verwendung von Übergabevariablen und „normalen“ Variablen.

12. Verwende sprechende Variablennamen

Versuche eine Balance zu finden zwischen Variablennamen wie x und Das_Ist_Die_Straße_Des_Kunden. Die Namen einer Variablen sollen selbsterklärend sein, aber nicht die Dokumentation ersetzen.

13. Dokumentiere Deine Programme

Unabhängig, ob Du alleine an einem Projekt arbeitest oder im Team, Du wirst Probleme beim Verstehen des Codes einer anderen Person oder eines alten, eigenen Codes haben.
Erkläre in den Kommentaren die Funktion der Proceduren, die Übergabevariablen und die Rückgabe. Nimm Stellung dazu wann die letzte Änderung war und von wo aus die Procedur aus genutzt wird.

14. Benutze Standard Programierelemente

Verwende die Grundkomponenten des VBA wie If..End If, Do..Loop, For..Next, With..End With, While..Wend, Select Case .. End Select, Type..End Type, etc und verzichte auf exotische Strukturen, die möglicherweise in der nächsten Version nicht mehr enthalten sind.
Nutze die Anfangs und Endstrukturen um Deinen Code übersichtlich zu strukturieren. Rücke mittels Tab Taste den dazwischen liegenden Code ein, um eine klare Zuordnung zwischen den Strukturen und den darin enthaltenen Code zu schaffen.Die Sprungweite von 4 Zeichen je Tab kannst Du in den Optionen einstellen.

15. Vermeide Ein-Zeilen Programme

Schreibe keine einzeiligen Strukturen, sie sind schwer zu verstehen und schlecht zu debuggen.
If vAnzahl>0 then DoCmd.OpenForm „frmOpen“

Nutze besser
If vAnzahl>0 then
DoCmd.OpenForm „frmOpen“
End If

16. Benutze das Select Case korrekt

Die Select Case Struktur ist bestens dafür geeignet eine Variable in den unterschiedlichsten Ausprägungen zu überprüfen
Trenne die Entscheidung von der Folge
Schlecht :
Select Case vLand
Case Is = „Deutschland“ : Rechtsstatus = „Legal“
Case Is = „Polen“ : Rechtsstatus = „Duldungl“
End If

Gut :
Select Case vLand

Case Is = „Deutschland“
Rechtsstatus = „Legal“

Case Is = „Polen“
Rechtsstatus = „Duldung“

End If

Und was ist mit all den anderen Ländern ! Verwende immer eine Case Else Anweisung, um auch die seltenen Fälle abzufangen
Case Else
Rechtsstatus = „Kein Status vorhanden für das aktuelle Land“

17. Verwende keine Stopmarke zum Debuggen

Das üble an Stopmarken ist, das mann sie leider leicht vergessen kann, wie peinlich, wenn der Anwenden sie „findet“. Verwende an Stelle dessen lieber Haltemarken, sie verschwinden spätestens beim Schließen des Access und können den Anwender nicht „überraschen“