Thema System
In strukturiertem VBA-Code findet sich nach dem Namen der Prozedur meistens die Definition der Objekte und Variablen, dann das Füllen mit Inhalten und danach der Code für Controls, Funktionen usw. Bei mir findet man in der ersten Zeile sehr häufig den Aufruf System. Warum das? Weil ich ein fauler Hund bin
Ich habe einfach keine Lust, bestimmte Dinge in jeder Sub wieder zu schreiben, also nutze ich dafür gerne (soweit technisch sicher!) Public Variablen und definiere die genau einmal.Beispiel: Eine Arbeitsmappe mit einer fixen Anzahl von Arbeitsblättern in meiner Nomenklatur (s.u.) beginnend mit dem Prefix ws (Worhsheet, andere nutzen sht), einem, maximal zwei Großbuchstaben, die den Blattnamen erkennen lassen und ggf. deren Sichtbarkeit. Außerdem platziere in diesem Modul, das immer den Namen modSystem (in frühen Projekten auch mal modCommons) z.B. APIs oder Public Arrays.
Vorstellen kann man sich das Ganze ein wenig wie die Beziehung HTML und CSS. Eine Änderung in der CSS wirkt sich einfach direkt auf alle HTML-Seiten aus. Beispiele dazu finden sich in wohl jeder hier von mir eingestellten Beispieltabelle.
Thema Nomenklatur
Man hat mich immer wieder in Foren darauf hinwiesen, dass es hilfreich wäre, sprechende Variablennamen zu verwenden. Hier knurrt aber wieder der faule Hund. Für immer wieder benötigte Variablen, verwende ich immer den gleichen Variablennamen, bzw. die gleichen Präfixe. Private Standards (innerhalb einer Prozedur) wie integer, strings beginnen mit i, s, gefolgt von einer 3-Buchstaben Abk. iPos(ition), sCap(tion). Für Iteratoren verwende ich i, benötige ich einen zweiten ii. Zeilen/Spalten werden immer mit r & c (Rows & Columns) benannt, benötige ich eine zweite ist's z und s (Zeile & Spalte). Ein einfaches a steht immer für Anzahl, als Präfix kennzeichnet es ein Array Diese Namen benötigen, die Nomenklatur konsequent eingehalten, keine ausführliche Tipperei und sind leicht nachzuvollziehen.
Meine Erfahrung sagt mir, dass es unzählige andere Methoden gibt, sowohl Code-Faulheit zu unterstützen, als auch Namensregeln aufzustellen, die Übersichtlichkeit schaffen. Das Schöne am Menschen ist seine Kreativität. Nachdem es erst einmal nur ich bin, der meinen Code verstehen muss, nutze ich also mein System und füge für andere später gerne einen erläuternden Kommentar hinzu.
Schon erlebt habe ich, dass es Kollegen gibt, die ihre Methode schon beinahe dogmatisch vertreten. Davon bin ich weit entfernt - denn: Jeder so, wie er/sie/das Team sich sicher zurechtfinden. Als Merkzettel hilft mir folgende Grafik:
Viel Spaß damit
Grüße
