Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 4/2008.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Lernen Sie die Grundlagen kennen, um leicht lesbaren und wartbaren VBA-Code zu produzieren.

Techniken

VBA

Voraussetzungen

Access 2000 oder höher

Beispieldateien

-

Shortlink

620

Effizientes Codieren

André Minhorst, Duisburg

Wer gut zu wartenden und lesbaren Code schreiben möchte, der überdies möglichst wenig fehleranfällig sein soll, braucht keine dicken Bücher zu studieren. Dieser Beitrag zeigt einige einfache Möglichkeiten, die Qualität seines Codes zu verbessern.

Explizite Deklaration

Im Auslieferungszustand brauchen Sie unter Access keine Variable zu deklarieren. Das heißt, Sie können einer Variablen strText einfach einen Text zuweisen, ohne dass eine Deklaration vonnöten wäre:

strText = "Beispieltext"

Diesen Text verarbeiten Sie dann später, indem Sie beispielsweise eine der Zeichenketten-Funktionen von VBA darauf loslassen.

Da die Variable aber nicht deklariert ist, können Sie ihr auch jegliche andere Information zuweisen - so auch Verweise auf Objekte wie etwa ein Database-Objekt:

Set strText = CurrentDB

Wenn man strText später mit einer der Zeichenketten-Funktionen untersuchen möchte, löst dies natürlich einen Fehler aus.

Dies passiert sicher nicht, wenn der VBA-Editor Sie zwingt, alle Variablen unter Angabe des Datentyps zu deklarieren. Dreh- und Angelpunkt ist eine einfache Anweisung, die Sie im Kopf des Moduls platzieren:

Option Explicit

Nicht deklarierte Variablen führen beim Kompilieren der Anwendung nun zu einem Laufzeitfehler. Wenn Sie sicherstellen möchten, dass die Option Explicit-Anweisung automatisch hinzugefügt wird, wenn Sie ein neues Modul anlegen, brauchen Sie nur die Option Variablendeklaration erforderlich im Optionen-Dialog des VBA-Editors (Extras|Optionen) zu aktivieren (s. Abb. 1).

pic001.tif

Abb. 1: Die Option Variablendeklaration erforderlich sorgt dafür, dass jedes neue Modul automatisch die Zeile Option Explicit erhält.

Variant vermeiden

Der Datentyp Variant ist der flexibelste aller Datentypen. Dafür benötigt er aber auch eine Menge Speicherplatz. Er kann alle Datentypen aufnehmen, selbst Verweise auf Objekte, und zusätzlich - das macht diesen Datentyp überhaupt so interessant - kann er als einziger Datentyp Werte wie Null oder Empty enthalten.

Den Variant-Datentyp setzen Sie beispielsweise für die folgenden Zwecke ein:

  • Sie wissen nicht, welchen Datentyps ein Wert ist.
  • Sie müssen auf Null prüfen. Das erledigen Sie mit der IsNull-Funktion. Beispiel:

If IsNull(DLookup("ID", "tblKontakte", "_

    Nachname = 'Minhorst'") Then

    MsgBox "Kein Datensatz gefunden."

End If

  • Sie müssen prüfen, ob eine Variable einen Wert enthält. Diese Aufgabe übernimmt die Funktion IsMissing. Einsatzort sind Prozeduren mit optionalen Parametern. Beispiel:

Public Sub TestAufEmpty(Optional var As _

        Variant)

    If IsMissing(var) Then

        MsgBox "Kein Parameter übergeben."

    End If

End Sub

Nicht jedem ist bekannt, dass eine nicht explizit deklarierte Variable automatisch den Datentyp Variant erhält. Das gilt beispielsweise für eine Deklaration wie diese:

Dim var

Das folgende Beispiel tritt ebenfalls immer wieder auf, wenn es um Probleme mit Variablen geht:

Dim str1, str2 As String

Es erhalten keinesfalls beide Variablen den Datentyp String, sondern nur str2. str1 wird hier als Variant deklariert. Sie können das mit der folgenden Routine prüfen:

Public Sub VarOderNichtVar()

    Dim str1, str2 As String

    Debug.Print "str1", VarType(str1), _

        TypeName(str1)

    Debug.Print "str2", VarType(str2), _

        TypeName(str2)

End Sub

Im Direktfenster erscheint das folgende Ergebnis:

str1 0 Empty

str2 8 String

Ordnung muss sein

Lesbaren und gut zu wartenden Code kann man unter zwei Aspekten betrachten. Die beiden unterscheiden sich dadurch, ob jemand anderes als Sie selbst jemals einen Blick auf Ihren Code werfen wird. Falls nicht, können Sie Ihre eigenen Regeln aufstellen - Hauptsache, Sie finden sich zurecht. Wenn aber, wie es Fachautoren zu diesem Thema ist, noch andere auf Ihren Code schauen und diesen auch noch verstehen oder gar anpassen sollen, gibt es gewisse Grundregeln, die Sie beachten sollten:

  • Verwendung einer Namenskonvention
  • Sprechende Bezeichnungen für Variablen und Routinen
  • Optische Aufbereitung des Codes

Die nächsten Abschnitte stellen diese Grundregeln vor, denen Sie zwar nicht folgen müssen, die aber die Kommunikation vereinfachen.

Verwendung einer Namenskonvention

Namenskonventionen sind ein treffliches Thema für Diskussionen. Dabei geht es meist gar nicht um die Namen selbst, sondern um die Präfixe. Es gibt zwar eine Notation namens Reddick Naming Convention (s. http://www.xoc.net/standards/rvbanc.asp), aber längst nicht alle Entwickler verwenden diese.

Manche verzichten aus Nachlässigkeit einfach ganz auf Präfixe, andere bringen eigene Konventionen von anderen Programmiersprachen mit. Letztlich hat sich auch die Reddick Naming Convention nicht zu hundert Prozent durchgesetzt, aber immerhin verwenden Entwickler die gängigen Präfixe wie etwa str für eine String-Variable.

Da wir hier über VBA sprechen, fallen die Access-Objekte und darin enthaltene Steuerelemente weg; bleibt also alles, was sich so im Codefenster herumtreibt. VBA-Routinen versieht niemand mit einem Präfix. Hin und wieder tauchen Funktionen mit vorangestelltem fct oder fu auf, aber das ist eher die Ausnahme.

Bleiben die Variablen: Die Basistypen sollten Sie grundsätzlich mit einem Präfix entsprechend der Reddick-Konvention ausstatten, allein damit man den Datentyp erkennen kann, ohne in längeren Prozeduren immer zum Deklarationsbereich der Prozedur oder des Moduls wandern zu müssen.

Ein interessantes Thema ist die Benennung von Objektvariablen, etwa für den Verweis auf Formulare, Berichte, Steuerelemente, Klassen oder auch externe Objekte wie etwa Anwendungen (Excel, Word, Outlook et cetera) und deren Elemente.

Objektverweise auf andere Anwendungen nennt man - am Beispiel von Excel - zum Beispiel objExcel oder einfach xls:

Dim objExcel As Excel.Application

Auch für die Benennung der Objekte externer Anwendungen gibt es mehrere Alternativen: Entweder Sie benutzen, wenn das Objekt nur einmal in einer Routine vorkommt, das Präfix obj plus den Objektnamen, also beispielsweise objRange, oder deuten zumindest die Stammanwendung an, indem Sie statt des obj ein xls voranstellen (xlsRange).

Die meisten werden auch die Bezeichnung rng zuordnen können. Wenn es mehrere gleichartige Objekte im Code gibt, sollte man ein wenig detaillierter auf die jeweilige Verwendung eingehen und ein von der Objektart abhängiges Kürzel mit einem weiteren Ausdruck verwenden (für Range also beispielsweise rngZiel).

Präfixe für Steuerelemente

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

VBA-Code mit Doxygen dokumentieren

Grundlagen der Quellcodeverwaltung

Rund um Binärzahlen

Optionen in Properties speichern

Formulare generieren

Modale Dialoge mal anders

TreeView-Konfigurator

Erweitern des VBA-Editors

Validieren mit Klasse

Zugriff auf Formulare

Das Optionsgruppen-Steuerelement

Prozedurbrowser für den VBA-Editor

VBA-Code bearbeiten

Ereignisse im Eigenbau

Schnittstellenvererbung

Das Factory-Pattern

Fehlersuche und –behandlung mit Access

© 2003-2015 André Minhorst Alle Rechte vorbehalten.