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.
Lösung
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"