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 (siehe Bild 1).

pic001.tif

Bild 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

In diesem Fall macht dies natürlich nur wenig Sinn, denn Access erkennt die Eigenschaften der eingebauten Steuerelemente auch so.

Die Programmierung eines TreeViews oder anderer externer Steuerelemente stellt sich jedoch unter Umständen als unkomfortabel heraus, wenn man keine passenden Objektvariablen für sie deklariert, denn der VBA-Editor zeigt für direkte Verweise auf solche Objekte im Formular kein IntelliSense an.

Ein Verweis darauf spart deshalb eine Menge Arbeit. Auch hier stellt sich aber die Frage, wie man die nötige Objektvariable benennt. Ein TreeView-Steuerelement erhält im Formular normalerweise einen Namen wie ctlTreeView oder, wenn es etwas genauer sein soll, zum Beispiel tvwProjekte.

In Access im Unternehmen halten wir es bei solchen Steuerelementen, die in der Regel nur einmal je Formular auftauchen, meist so, dass wir das Steuerelement ctlTreeView nennen und eine darauf verweisende Objektvariable objTreeView.

Sprechende Bezeichnungen für Variablen und Routinen

Neben dem Präfix ist der Name einer Variable äußerst wichtig. Sie und auch andere sollten mit einem Blick erkennen können, was die Variable für einen Wert speichert – und das zusätzlich zum Erkennen des Datentyps über das Präfix. Negativbeispiele sind solche, die nur ein Präfix und eine Zahl enthalten, also zum Beispiel str1 und str2. Aussagekräftig sind Variablennamen wie lngAnzahlKontakte.

Genauso wichtig wie bei Variablen ist die sprechende Bezeichnung für Routinen, was gleichermaßen für Sub– und Function-Prozeduren gilt. Der Name sollte kurz und bündig beschreiben, was die Routine erledigt. Probleme beim Finden eines Routinennamens sind übrigens ein gutes Indiz dafür, dass eine Routine zu viele Aufgaben erledigt – mehr dazu erfahren Sie weiter unten unter Eine Routine pro Aufgabe.

Englisch oder Deutsch

Ob man englische oder deutsche Objekt-, Routinen- und Variablennamen verwendet, ist eine persönliche Entscheidung, wenn man nicht gerade Software für internationale Kunden entwickelt. Die Frage stellt sich, weil die Benutzeroberfläche einer Anwendung in der Regel in der jeweiligen Landessprache gehalten ist, während Programmiersprachen immer englisch sind (wer Ausnahmen kennt, darf dies gern mitteilen!).

Sie müssen also die Elemente, die sich zwischen Benutzeroberfläche und Programmiersprache befinden, irgendwo zwischen den beiden Sprachen einordnen. Manche gestalten bereits die Tabellen und Felder des Datenmodells in englischer Sprache, was sich natürlich im Quellcode und gar in den darin enthaltenen Kommentaren fortsetzt. Bei anderen findet man außer den eingebauten Bezeichnungen etwa der Programmiersprache nur Texte in der Landessprache.

Optische Aufbereitung des Codes

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

den kompletten Artikel im PDF-Format mit Beispieldatenbank

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar