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<\/p>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 1507_CodeLayout.accdb<\/b><\/p>\nStrukturierung<\/h2>\n
Umso logischer Ihr Code aufgebaut ist, desto mehr Freude werden Sie später an ihm haben. Später<\/b> 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<\/p>\nModulstrukturen<\/h2>\n
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.<\/p>\n
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<\/b>, sagt wenig über den Inhalt aus. Besser fahren Sie da etwa mit mdlFileAccess<\/b>, mdlDataAccessDAO<\/b>, mdlStringHandling<\/b>.<\/p>\n
ä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<\/b> oder mod<\/b> zum Einsatz, für Klassenmodule ein cls<\/b> oder schlicht ein großes C<\/b>. 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.<\/p>\n
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.<\/p>\n
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<\/b> (Beim öffnen<\/b>) ist das erste Ereignis, das ein Formular auslöst. Gefolgt wird es von Form_Load<\/b> (Beim Laden<\/b>) und schließlich Form_Current<\/b> (Beim Anzeigen<\/b>). Das Schließen des Formulars löst Form_Close<\/b> (Beim Schließen<\/b>) und Form_Unload<\/b> (Beim Entladen<\/b>) 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.<\/p>\n
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.<\/p>\n
Allerdings gibt es hier in punkto Lesbarkeit auch Einschränkungen. Nehmen Sie etwa folgenden Pseudocode:<\/p>\n
Funktion A()\r\n [Code]\r\n Call<\/span> Funktion B\r\n [Code]\r\nEnde Funktion A\r\nFunktion B()\r\n [Code]\r\nEnde Funktion B<\/pre>\nFunktion B<\/b> wird also von Funktion A<\/b> benötigt und aufgerufen. Als Hilfsprozedur fände Sie weiter unten im Modul ihren Platz. Stießen Sie in Funktion A<\/b> bei Durchsicht später auf den Aufruf von B<\/b>, so müssten Sie weit nach unten scrollen, oder über das Kontextmenü den Eintrag Definition<\/b> auswählen, um zur Hilfsfunktion B<\/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<\/b> von mehreren Prozeduren benötigt, sähe das zum Beispiel so aus:<\/p>\nFunktion A()\r\n [Code]\r\n Call<\/span> Funktion C\r\n [Code]\r\nEnde Funktion A\r\nFunktion B()\r\n [Code]\r\n Call<\/span> Funktion C\r\nEnde Funktion B\r\nFunktion C()\r\n [Code]\r\nEnde Funktion C\r\nFunktion D()\r\n [Code]\r\nEnde Funktion D<\/pre>\nüberhaupt ist die Frage, in wie viele Prozeduren eine Aufgabe aufgeteilt werden kann und soll. Im Beispiel hätte man auf die Hilfsfunktion C<\/b> ja auch verzichten und deren Code wiederholt in Prozedur A<\/b> und B <\/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<\/b>) vollzogen werden, statt an mehreren. Und zweitens sind kürzere Prozeduren leichter überschaubar, als Spaghetti-Code, der sich länglich hinzieht.<\/p>\n
Dennoch sollte man diese Strukturierung auch nicht zu weit treiben. Wenn Funktion A <\/b>die Funktion B<\/b> aufruft, diese wiederum Funktion C<\/b>, und C<\/b> verlangt nach D<\/b>, dann ist zum Verstehen von A die ganze verteilte Kette B<\/b> bis D<\/b> 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.<\/p>\nProzedurstrukturierung<\/h2>\n
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.<\/p>\n
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.<\/p>\n
Andere Deklarationen<\/h2>\n
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.<\/p>\n
Option Compare Database<\/span>\r\nOption Explicit<\/span>\r\n'öffentliche Konstanten\r\nPublic <\/span>Const GWL_STYLE As Long<\/span> = -16\r\nPublic <\/span>Const GWL_WNDPROC As Long<\/span> = -4\r\n'Private Konstanten\r\nPrivate <\/span>Const GW_CHILD As Long<\/span> = 5\r\nPrivate <\/span>Const GW_HWNDFIRST As Long<\/span> = 0\r\nPrivate <\/span>Const GW_HWNDLAST As Long<\/span> = 1\r\nPrivate <\/span>Const GW_HWNDPREV As Long<\/span> = 3\r\n'öffentliche Typen\r\nPublic <\/span>Type Guid\r\n Data1 As Long<\/span>\r\n Data2 As Integer<\/span>\r\n Data3 As Integer<\/span>\r\n Data4(0 To 7) As Byte<\/span>\r\nEnd Type\r\n'Private Typen\r\nPrivate <\/span>Type LUID\r\n LowPart As Long<\/span>\r\n HighPart As Long<\/span>\r\nEnd Type\r\n'öffentliche API-Funktionen\r\nPublic <\/span>Declare Function GetWindow Lib \"user32.dll\" ( _\r\n ByVal hwnd As Long<\/span>, _\r\n ByVal wCmd As Long<\/span>) As Long<\/span>\r\n'Private API-Funktionen\r\nPrivate <\/span>Declare Function SetWindowPos Lib \"user32.dll\" ( _\r\n ByVal hwnd As Long<\/span>, _\r\n ByVal hWndInsertAfter As Long<\/span>, _\r\n ByVal x As Long<\/span>, _\r\n ByVal y As Long<\/span>, _\r\n ByVal cx As Long<\/span>, _\r\n ByVal cy As Long<\/span>, _\r\n ByVal wFlags As Long<\/span>) _\r\n As Long<\/span>\r\n \r\n'öffentliche Variablen\r\nPublic <\/span>dbs As <\/span>DAO.Database\r\n'Private Variablen\r\nPrivate <\/span>i As Long<\/span>, j As Long<\/span>\r\n'Prozeduren --------------------<\/pre>\nListing 1: Beispiel für Deklarationen in einem Modulkopf<\/p>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t