Home > Artikel > Ausgabe 7/2015 > Besseres Code-Layout

Besseres Code-Layout

Achtung: Sie sind nicht angemeldet. Wenn Sie Abonnent sind und sich anmelden, lesen Sie den kompletten Artikel, laden das PDF herunter oder probieren die Beispieldatenbank aus (sofern vorhanden).

Die Lesbarkeit von Programmcode beschleunigt sowohl die Entwicklung, wie auch die Wartung Ihrer Anwendungen. Wenn Sie ein Freund der VBA-Programmierung sind, so überprüfen Sie Ihre Routinen doch einmal auf Struktur und Gestalt. Gibt es hier Verbesserungspotential?

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1507_CodeLayout.accdb

Strukturierung

Umso logischer Ihr Code aufgebaut ist, desto mehr Freude werden Sie später an ihm haben. Später kann dabei bedeuten, dass Sie schon am nächsten Tag möglichst schnell wieder in die Routinen hineinfinden und nicht unnötig Zeit damit verbringen müssen, die Funktionsabfolgen mühsam nachzuvollziehen. Erst recht gilt dies, wenn Sie sich zur Wartung oder Weiterentwicklung nach einem Jahr wieder an eine Datenbank machen müssen. Früher galt einmal das Credo, den Code ausführlich zu kommentieren, um später so einen Leitfaden vorzufinden, doch was nützt eine Kommentierung oder Dokumentation, wenn die Struktur unzureichend ist?

Modulstrukturen

Sie finden Funktionen leichter auf, wenn Sie sie auf mehrere Module aufteilen, statt alles in ein Modul zu packen. Sie haben eine Sammlung von immer wieder gebrauchten Routinen, etwa Dateifunktionen, Datumsberechnungen, String-Operationen und solche für den Datenzugriff? Leicht können dies Hunderte werden, auf die der Zugriff, falls in nur in einem Modul gespeichert, umständlich wird. Die Navigation ist behindert und ausdauerndes Scrollen wird notwendig. Der Überblick geht verloren.

Da ist es günstiger, wenn Sie Routinen mit ähnlicher Funktionalität in thematisch passenden Modulen vereinen. Legen Sie ein Modul für die Dateioperationen an, eines für die String-Bearbeitung und eines für für den Datenzugriff. Damit Sie dann wissen, um was es sich handelt, sind sprechende Namen für die Module angeraten. Eine Bezeichnung, wie mdlFunktionen, sagt wenig über den Inhalt aus. Besser fahren Sie da etwa mit mdlFileAccess, mdlDataAccessDAO, mdlStringHandling.

Ähnlich, wie bei Variablen- oder Steuerelementnamen hat sich die Verwendung von Präfixen eingebürgert. Für normale Module kommt meist das Präfix mdl oder mod zum Einsatz, für Klassenmodule ein cls oder schlicht ein großes C. Englische Bezeichnungen oder deutsche? Das bleibt Ihnen überlassen. Da jedoch davon auszugehen ist, dass die meisten Programmierer mit englischen Fachbegriffen vertraut sind, liegt man mit englischen Bezeichnungen auf der sicheren Seite. So ist sichergestellt, dass es nicht zu Konfusionen kommt, wenn die Datenbankanwendung oder einzelne Module einmal die Ländergrenzen überschreiten sollten.

Die Frage, wie kleinteilig man Routinen auf Module verstreut, ist schwer zu beantworten. Natürlich könnten Sie Ihre Module so gestalten, dass der Code immer komplett auf eine Bildschirmseite passt. Das aber würde zu überhäufigem Umschalten zwischen den Modulen führen – schließlich werden die Prozeduren ja wahrscheinlich von anderen aufgerufen. Je umfangreicher andererseits ein Modul ausfällt, desto mehr Scrollen ist angesagt. Finden Sie hier also einen Mittelweg.

Prozedurstrukturen

Innerhalb eines Moduls macht eine logische Anordnung der Prozeduren ebenfalls Sinn. Was hier logisch ist, oder nicht, hängt von der Bedeutung der Routinen ab. Nehmen Sie etwa ein Formularmodul. Sinnvoll wäre hier eine Anordnung in der chronologischen Abfolge von Ereignissen. Form_Open (Beim Öffnen) ist das erste Ereignis, das ein Formular auslöst. Gefolgt wird es von Form_Load (Beim Laden) und schließlich Form_Current (Beim Anzeigen). Das Schließen des Formulars löst Form_Close (Beim Schließen) und Form_Unload (Beim Entladen) aus. Also würde eine Anordnung solcher Ereignisprozeduren von oben nach unten später nützlich sein. Ähnliches gilt für die Steuerelementereignisse, die sich an die Formularereignisse anschließen könnten. Hilfsfunktionen, die von diesen Ereignisprozeduren aufgerufen werden, dürfen getrost ganz unten im Modul ihren Raum finden.

Auch bei normalen Modulen ist eine Anordnung der Routinen von bedeutsam bis Hilfsfunktion in vertikaler Richtung praktisch. Denn beim Öffnen eines Moduls werden Sie in der Regel mit den ersten Zeilen konfrontiert. Da macht es sich gut, wenn hier gleich die relevantesten Code-Teile zu finden sind.

Allerdings gibt es hier in punkto Lesbarkeit auch Einschränkungen. Nehmen Sie etwa folgenden Pseudocode:

Funktion A()

     [Code]

     Call Funktion B

     [Code]

Ende Funktion A

Funktion B()

     [Code]

Ende Funktion B

Funktion B wird also von Funktion A benötigt und aufgerufen. Als Hilfsprozedur fände Sie weiter unten im Modul ihren Platz. Stießen Sie in Funktion A bei Durchsicht später auf den Aufruf von B, so müssten Sie weit nach unten scrollen, oder über das Kontextmenü den Eintrag Definition auswählen, um zur Hilfsfunktion B zu gelangen. Besser ist es da, wenn die Hilfsfunktion direkt nach der aufrufenden steht. Versuchen Sie, die Prozedurreihenfolge möglichst kompakt zu halten. Würde Funktion C von mehreren Prozeduren benötigt, sähe das zum Beispiel so aus:

Funktion A()

     [Code]

     Call Funktion C

     [Code]

Ende Funktion A

Funktion B()

     [Code]

     Call Funktion C

Ende Funktion B

Funktion C()

     [Code]

Ende Funktion C

Funktion D()

     [Code]

Ende Funktion D

Überhaupt ist die Frage, in wie viele Prozeduren eine Aufgabe aufgeteilt werden kann und soll. Im Beispiel hätte man auf die Hilfsfunktion C ja auch verzichten und deren Code wiederholt in Prozedur A und B einsetzen können. Hier gilt aber der Grundsatz, dass wiederverwendbarer Code sich nicht wiederholen, sondern in eigene Funktionen ausgelagert werden sollte. Erstens macht es die Routinen abermals besser wartbar, denn Änderungen oder Weiterentwicklungen müssen so nur an einer Stelle (Funktion C) vollzogen werden, statt an mehreren. Und zweitens sind kürzere Prozeduren leichter überschaubar, als Spaghetti-Code, der sich länglich hinzieht.

Dennoch sollte man diese Strukturierung auch nicht zu weit treiben. Wenn Funktion A die Funktion B aufruft, diese wiederum Funktion C, und C verlangt nach D, dann ist zum Verstehen von A die ganze verteilte Kette B bis D zu überblicken. Ist das Ganze dann auch noch über mehrere Module verteilt, dann kann von Überblick eben keine Rede mehr sein. Von sehr komplexen Aufgaben abgesehen, sollte daher in der Regel die Verteilung der Funktionalität auf ein bis zwei Unterebenen ausreichen.

Prozedurstrukturierung

Innerhalb einer Prozedur gibt es eine Menge Gestaltungspotential. Neben dem reinen Layout, auf das wir später noch zu sprechen kommen, fragt sich etwa, wo sich die Dim-Anweisungen zur lokalen Variablendeklaration befinden sollten.

Meist stehen diese ganz am Anfang, müssen dies aber nicht. VBA ist es egal, ob die Variablen alle versammelt zu Anfang deklariert werden, oder irgendwo mitten im Code stehen. Zwar ist es weniger fehleranfällig, wenn die Dim-Anweisungen in einem Block stehen, bei Routinen mit 20 Variablen aber ist dieser Block dann schon ziemlich umfangreich. Stoßen Sie in der Prozedur auf eine Variablenzuweisung, haben den Datentyp der Variablen aber nicht mehr im Kopf, so ist abermals Scrollen zum Prozedurkopf angesagt. Aus diesem Grund kann es sinnvoll sein, die Variablendeklarationen in langen Prozeduren in mehrere Blöcke aufzuteilen. Variablen, die erst weiter unten verwendet werden, könnten dazu eben auch erst später in einem gesonderten Block deklariert werden. Das erhöht wieder die Übersichtlichkeit.

Andere Deklarationen

Im Kopf eines Moduls stehen die Deklarationen zu modulweit oder global gültigen Variablen, sowie gegebenenfalls die API-Deklarationen. Unter Umständen sammelt sich hier viel an, wie etwa Listing 1 zeigt.

Option Compare Database

Option Explicit

'Öffentliche Konstanten

Public Const GWL_STYLE As Long = -16

Public Const GWL_WNDPROC As Long = -4

'Private Konstanten

Private Const GW_CHILD As Long = 5

Private Const GW_HWNDFIRST As Long = 0

Private Const GW_HWNDLAST As Long = 1

Private Const GW_HWNDPREV As Long = 3

'Öffentliche Typen

Public Type Guid

     Data1 As Long

     Data2 As Integer

     Data3 As Integer

     Data4(0 To 7) As Byte

End Type

'Private Typen

Private Type LUID

     LowPart As Long

     HighPart As Long

End Type

'Öffentliche API-Funktionen

Public Declare Function GetWindow Lib "user32.dll" ( _

     ByVal hwnd As Long, _

     ByVal wCmd As Long) As Long

'Private API-Funktionen

Private Declare Function SetWindowPos Lib "user32.dll" ( _

     ByVal hwnd As Long, _

     ByVal hWndInsertAfter As Long, _

     ByVal x As Long, _

     ByVal y As Long, _

     ByVal cx As Long, _

     ByVal cy As Long, _

     ByVal wFlags As Long) _

     As Long

     

'Öffentliche Variablen

Public dbs As DAO.Database

'Private Variablen

Private i As Long, j As Long

'Prozeduren --------------------

Listing 1: Beispiel für Deklarationen in einem Modulkopf

Es ist nützlich, wenn Sie wissen, wo Sie hier was finden können. Stoßen Sie im Code einer Prozedur auf eine Konstantenbezeichnung und möchten deren Wert erfahren, so ist es einfacher, einen Block von Konstanten zu begutachten, als den gesamten Modulkopf nach ihr abzusuchen.

Packen Sie also besser alle Konstanten in einen Block und verfahren Sie mit Typdefinitionen, API-Deklarationen und Variablen genauso. Wenn Sie immer den gleichen Aufbau erzeugen, finden Sie später schneller die gewünschte Stelle im Modulkopf.

Als geeignet hat sich dabei dieser Aufbau erwiesen: Stellen Sie Konstanten ganz oben ins Modul. Das ist nicht unwichtig, denn unter Umständen kommen diese Konstanten im weiteren Verlauf in Typen oder API-Funktionen zum Einsatz. VBA findet diese Konstanten aber nur dann, wenn Sie vor diesen Definitionen deklariert wurden. Dasselbe gilt für die Typendefinitionen im folgenden Block. API-Funktionen oder Variablen könnten ebenfalls nach benutzerdefinierten Typen verlangen, die dann bereits zuvor im Modul definiert sein müssen. Für Typdefinitionen gibt es noch eine weitere Besonderheit, wie folgendes Beispiel zeigt:

Private Type XYZ

     X As Long

     Y As Long

     N As ABC

End Type

Private Type ABC

     A As Integer

     B As Integer

     C As Long

End Type

Das wird VBA nicht zulassen, weil der Typ XYZ im Element N den Typ ABC benötigt, jener aber erst später folgt. Die umgekehrte Reihenfolge ist nötig!

An den Block der Typdefinitionen schließen Sie die API-Deklarationen an. Zum Schluss folgen die Variablendeklarationen, denn diese stehen den Prozeduren quasi am nächsten.

Da alle Deklarationen sowohl private, wie auch öffentliche Gültigkeit aufweisen können, ist zudem ein Aufteilen in diese Gültigkeitsbereiche sinnvoll. Stellen Sie etwa erst alle öffentlichen Elemente zusammen, dann die privaten, so, wie auch im Listing geschehen.

Prozedur-Layout

Hier geht es um die optische Gestaltung des Code. Führen Sie sich dazu das Negativbeispiel in Listing 2 zu Gemüte.

Public Function fuCodeLayout(Optional ByVal x As Long, Optional _

Sie haben das Ende des frei verfügbaren Teil dieses Artikels erreicht!

Wenn Sie mehr lesen und auf viele weitere Artikel zugreifen möchten, melden Sie sich als Abonnent unter Login an. Falls nicht, bestellen Sie doch einfach ein Jahresabonnement!