Effizientes Codieren

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

Wenn Sie im Code Steuerelemente referenzieren, haben Sie auf zwei Arten zur Wahl. Entweder Sie verweisen direkt auf die Steuerelemente im Formular oder im Bericht oder Sie erzeugen Objektvariablen, in denen Sie den Verweis speichern.

Im ersten Fall übernehmen Sie schlicht die Bezeichnungen der Steuerelemente, beispielsweise so:

Debug.Print Me!txtBeispiel.Value

Im zweiten Fall brauchen Sie eine Objektvariable. Wenn Sie das dem Steuerelement entsprechende Präfix und auch eine den Inhalt repräsentierende Bezeichnung verwenden möchten, können Sie prinzipiell nur den Namen des Steuerelements als Variablennamen verwenden. Dies funktioniert ohne Probleme: Die folgende kleine Beispielroutine stammt aus einem Formular mit einem Textfeld namens txtBeispiel. Sie benennt die Variable für das Textfeld nach dem Namen des Steuerelements und weist diesem über den Objektverweis einen Wert zu:

Private Sub cmdTextfeldFuellen_Click()
    Dim txtBeispiel As Access.TextBox
    Set txtBeispiel = Me!txtBeispiel
    txtBeispiel = "Text"
End Sub

Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!
Hier geht es zur Bestellung des Jahresabonnements des Magazins Access im Unternehmen:
Zur Bestellung ...
Danach greifen Sie sofort auf alle rund 1.000 Artikel unseres Angebots zu - auch auf diesen hier!
Oder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:

Schreibe einen Kommentar