{"id":2070,"date":"2013-11-11T23:10:21","date_gmt":"2013-11-11T21:10:21","guid":{"rendered":"http:\/\/www.ramses.de\/?p=2070"},"modified":"2013-11-11T23:10:21","modified_gmt":"2013-11-11T21:10:21","slug":"faq-access-guter-vba-code","status":"publish","type":"post","link":"https:\/\/www.ramses.de\/?p=2070","title":{"rendered":"FAQ Access – Guter VBA Code"},"content":{"rendered":"
\n

Access VBA – Guter VBA Code<\/h1>\n<\/div>\n
\n

Problem <\/strong><\/h2>\n

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\u00df laufen (Keine Bugs), das Programm mu\u00df dokumentiert sein, das Programm mu\u00df schnell sein.<\/p>\n

L\u00f6sung <\/strong><\/h2>\n

Es versteht sich von selbst, dass man \u00fcber die folgenden Regeln trefflich diskutieren kann.<\/p>\n

Hier nun 17 Regeln zum Erstellen „guten“ VBA Codes<\/p>\n

1. Verwende Option Explicit<\/h3>\n

Die Function Explicit legt fest, da\u00df alle Variablen vor der Benutzung dimensioniert werden m\u00fcssen. Das verhindert das „Verschreiben“ bei der Benutzung der Variablen.<\/p>\n

2. Deklariere die Variablen korrekt<\/h3>\n

Jede Variable sollte in einer einzelnen Zeile deklariert werden. Dadurch verhindern wir, da\u00df durch falsche Deklaration eine Variant Variable entsteht.
\nDim a, b, c as String
\nIn diesem Beispiel ist nur c as String, a und b jedoch als Vairant deklariert.
\nDim a as String
\nDim as String
\nDim ca String<\/p>\n

\n3. Vermeide Variant Variablen<\/h3>\n

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\u00f6nnen unerwartete Ergebnisse bringen da keine Plausibilit\u00e4tskontrollen erfolgen.<\/p>\n

4. Verwende keine Typkennzeichen<\/h3>\n

Viele Variablen haben so genannte Typkennzeichen, so kann eine Variable als String definiert werden, indem das $ Zeichen als String Typkennzeichen verwendet wird :
\nDim Nachname$
\nDiese Art der Deklaration ist veraltet und nur aus Gr\u00fcnden der Abw\u00e4rtskompatibilit\u00e4t noch vorhanden. Nicht alle Variablentypen haben ein solches Kennzeichen.<\/p>\n

5. Achte auf die Reichweite Deiner Variablen<\/h3>\n

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\u00fcltigkeitsbereich nur innerhalb der Prozedur. Variablen mit zu gro\u00dfer Reichweite erschweren das Finden von Fehlern.<\/p>\n

6. Konvertiere Daten Typen explizit<\/h3>\n

Wenn wir die Daten aus einer Variable in eine andere packen, so wird bei unterschiedlicher Variablenart eine automatische Konvertierung vorgenommen. Das kann zu unerw\u00fcnschten Ergebnissen f\u00fchren. Wenn also aus einer Double Zahl eine Integer Zahl werden soll, so verwenden die Konvertierungsfunktion CInt() und packe die Flie\u00dfkommazahl Zahl nicht einfach in eine entsprechende Int Variable.<\/p>\n

7. Deklariere den R\u00fcckgabewert einer Funktion<\/h3>\n

Genau wie bei den Variablen sollte auch der R\u00fcckgabewert einer Funktion deklariert werden, andernfalls gibt die Funktion einen Varianttyp zur\u00fcck. Es bestehen die gleichen Probleme wie bei der mangelden Deklaration von Variablen<\/p>\n

8. Verwende eine robuste Fehlerabfangroutine<\/h3>\n

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\u00f6nen“ Fehlermeldung zu verw\u00f6hnen.<\/p>\n

9. Lege Wert auf die Kontrolle Deines Programms<\/h3>\n

Sprungm\u00f6glicheiten wie GoTo oder GoSub kommen aus der guten alten Zeit des BASIC. Dies hat nichts mehr mit der modularen Programmierung unter VBA zu tun.
\nW\u00e4hle das GoTo nur f\u00fcr die Fehlerroutine und schaffe nicht mehrere M\u00f6glichkeiten den Code zu verlassen (Exit Sub oder Exit Function). Unbehandelte Fehler und nicht geschlossene Objekte k\u00f6nnten sonst die Folge sein.<\/p>\n

10. Nutze Variablen anstelle von Konstanten<\/h3>\n

Versuche es zu vermeiden, feste Konstanten in dem Code zu verwenden, sonst verstehst Du Deinen eigenen Code nach kurzer Zeit nicht mehr
\nKindergeld = vKinderzahl * 150
\nWas soll die 150 darstellen ??
\nBenutze Variablen
\nvKindergeldsatz = 150
\nKindergeld = vKinderzahl * vKindergeldsatz
\nEin weiteres Problem dieser Konstanten ist, da\u00df bei einer \u00c4nderung die Konstante mehrfach im Code auftauchen kann und es damit sehr schwer ist, sie zu \u00e4ndern. Im Fall einer Variablen ist es nur an einer Stelle zu \u00e4ndern.<\/p>\n

11. Benutze Namenskonventionen<\/h3>\n

Bei der Benennung von Variablen solltest Du sinnvolle Namen nutzen. \u00c4hnlich 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\u00fcr die Verwendung von \u00dcbergabevariablen und „normalen“ Variablen.<\/p>\n

12. Verwende sprechende Variablennamen<\/h3>\n

Versuche eine Balance zu finden zwischen Variablennamen wie x und Das_Ist_Die_Stra\u00dfe_Des_Kunden. Die Namen einer Variablen sollen selbsterkl\u00e4rend sein, aber nicht die Dokumentation ersetzen.<\/p>\n

13. Dokumentiere Deine Programme<\/h3>\n

Unabh\u00e4ngig, 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.
\nErkl\u00e4re in den Kommentaren die Funktion der Proceduren, die \u00dcbergabevariablen und die R\u00fcckgabe. Nimm Stellung dazu wann die letzte \u00c4nderung war und von wo aus die Procedur aus genutzt wird.<\/p>\n

14. Benutze Standard Programierelemente<\/h3>\n

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\u00f6glicherweise in der n\u00e4chsten Version nicht mehr enthalten sind.
\nNutze die Anfangs und Endstrukturen um Deinen Code \u00fcbersichtlich zu strukturieren. R\u00fccke 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.<\/p>\n

15. Vermeide Ein-Zeilen Programme<\/h3>\n

Schreibe keine einzeiligen Strukturen, sie sind schwer zu verstehen und schlecht zu debuggen.
\nIf vAnzahl>0 then DoCmd.OpenForm „frmOpen“<\/p>\n

Nutze besser
\nIf vAnzahl>0 then
\nDoCmd.OpenForm „frmOpen“
\nEnd If<\/p>\n

16. Benutze das Select Case korrekt<\/h3>\n

Die Select Case Struktur ist bestens daf\u00fcr geeignet eine Variable in den unterschiedlichsten Auspr\u00e4gungen zu \u00fcberpr\u00fcfen
\nTrenne die Entscheidung von der Folge
\nSchlecht :
\nSelect Case vLand
\nCase Is = „Deutschland“ : Rechtsstatus = „Legal“
\nCase Is = „Polen“ : Rechtsstatus = „Duldungl“
\nEnd If<\/p>\n

Gut :
\nSelect Case vLand<\/p>\n

Case Is = „Deutschland“
\nRechtsstatus = „Legal“<\/p>\n

Case Is = „Polen“
\nRechtsstatus = „Duldung“<\/p>\n

End If<\/p>\n

Und was ist mit all den anderen L\u00e4ndern ! Verwende immer eine Case Else Anweisung, um auch die seltenen F\u00e4lle abzufangen
\nCase Else
\nRechtsstatus = „Kein Status vorhanden f\u00fcr das aktuelle Land“<\/p>\n

17. Verwende keine Stopmarke zum Debuggen<\/h3>\n

Das \u00fcble 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\u00e4testens beim Schlie\u00dfen des Access und k\u00f6nnen den Anwender nicht „\u00fcberraschen“<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"

Access VBA – Guter VBA Code Problem VBA Code zu schreiben ist einfach, aber guten VBA Code zu schreiben ist schwierig. Was zeichnet nun einen … Weiterlesen …<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[47,43],"tags":[58,82],"class_list":["post-2070","post","type-post","status-publish","format-standard","hentry","category-access","category-faq","tag-access-2010","tag-beziehungen"],"_links":{"self":[{"href":"https:\/\/www.ramses.de\/index.php?rest_route=\/wp\/v2\/posts\/2070","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ramses.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ramses.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ramses.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ramses.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2070"}],"version-history":[{"count":1,"href":"https:\/\/www.ramses.de\/index.php?rest_route=\/wp\/v2\/posts\/2070\/revisions"}],"predecessor-version":[{"id":2071,"href":"https:\/\/www.ramses.de\/index.php?rest_route=\/wp\/v2\/posts\/2070\/revisions\/2071"}],"wp:attachment":[{"href":"https:\/\/www.ramses.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2070"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ramses.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2070"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ramses.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2070"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}