<\/p>\n
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.<\/b><\/p>\n
Explizite Deklaration<\/p>\n
Im Auslieferungszustand brauchen Sie unter Access keine Variable zu deklarieren. Das heißt, Sie können einer Variablen strText <\/b>einfach einen Text zuweisen, ohne dass eine Deklaration vonnöten wäre:<\/p>\n Diesen Text verarbeiten Sie dann später, indem Sie beispielsweise eine der Zeichenketten-Funktionen von VBA darauf loslassen.<\/p>\n 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<\/b>-Objekt:<\/p>\n Wenn man strText <\/b>später mit einer der Zeichenketten-Funktionen untersuchen möchte, löst dies natürlich einen Fehler aus.<\/p>\n 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:<\/p>\n Nicht deklarierte Variablen führen beim Kompilieren der Anwendung nun zu einem Laufzeitfehler. Wenn Sie sicherstellen möchten, dass die Option Explicit<\/b>-Anweisung automatisch hinzugefügt wird, wenn Sie ein neues Modul anlegen, brauchen Sie nur die Option Variablendeklaration erforderlich <\/b>im Optionen-Dialog des VBA-Editors (Extras|Optionen<\/b>) zu aktivieren (siehe Bild 1).<\/p>\n Bild 1: Die Option Variablendeklaration erforderlich sorgt dafür, dass jedes neue Modul automatisch die Zeile Option Explicit erhält.<\/span><\/b><\/p>\n Der Datentyp Variant <\/b>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<\/b> oder Empty <\/b>enthalten.<\/p>\n Den Variant<\/b>-Datentyp setzen Sie beispielsweise für die folgenden Zwecke ein:<\/p>\n Nicht jedem ist bekannt, dass eine nicht explizit deklarierte Variable automatisch den Datentyp Variant <\/b>erhält. Das gilt beispielsweise für eine Deklaration wie diese:<\/p>\n Das folgende Beispiel tritt ebenfalls immer wieder auf, wenn es um Probleme mit Variablen geht:<\/p>\n Es erhalten keinesfalls beide Variablen den Datentyp String<\/b>, sondern nur str2<\/b>. str1 <\/b>wird hier als Variant <\/b>deklariert. Sie können das mit der folgenden Routine prüfen:<\/p>\n Im Direktfenster erscheint das folgende Ergebnis:<\/p>\n 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:<\/p>\n Die nächsten Abschnitte stellen diese Grundregeln vor, denen Sie zwar nicht folgen müssen, die aber die Kommunikation vereinfachen.<\/p>\n 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 <\/b>(s. http:\/\/www.xoc.net\/standards\/rvbanc.asp<\/b>), aber längst nicht alle Entwickler verwenden diese.<\/p>\n 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 <\/b>nicht zu hundert Prozent durchgesetzt, aber immerhin verwenden Entwickler die gängigen Präfixe wie etwa str <\/b>für eine String-Variable.<\/p>\n 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 <\/b>oder fu <\/b>auf, aber das ist eher die Ausnahme.<\/p>\n 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.<\/p>\n 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.<\/p>\n Objektverweise auf andere Anwendungen nennt man – am Beispiel von Excel – zum Beispiel objExcel <\/b>oder einfach xls<\/b>:<\/p>\n 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 <\/b>plus den Objektnamen, also beispielsweise objRange<\/b>, oder deuten zumindest die Stammanwendung an, indem Sie statt des obj <\/b>ein xls <\/b>voranstellen (xlsRange<\/b>).<\/p>\n Die meisten werden auch die Bezeichnung rng <\/b>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 <\/b>also beispielsweise rngZiel<\/b>).<\/p>\n Präfixe für Steuerelemente<\/p>\n 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.<\/p>\n Im ersten Fall übernehmen Sie schlicht die Bezeichnungen der Steuerelemente, beispielsweise so:<\/p>\n 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<\/b>. Sie benennt die Variable für das Textfeld nach dem Namen des Steuerelements und weist diesem über den Objektverweis einen Wert zu:<\/p>\n <\/p>\n In diesem Fall macht dies natürlich nur wenig Sinn, denn Access erkennt die Eigenschaften der eingebauten Steuerelemente auch so.<\/p>\n 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.<\/p>\n 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 <\/b>oder, wenn es etwas genauer sein soll, zum Beispiel tvwProjekte<\/b>.<\/p>\n 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 <\/b>nennen und eine darauf verweisende Objektvariable objTreeView<\/b>.<\/p>\n 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<\/b> und str2<\/b>. Aussagekräftig sind Variablennamen wie lngAnzahlKontakte<\/b>.<\/p>\n Genauso wichtig wie bei Variablen ist die sprechende Bezeichnung für Routinen, was gleichermaßen für Sub<\/b>– und Function<\/b>-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<\/b>.<\/p>\n Englisch oder Deutsch<\/p>\n 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!).<\/p>\n 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.<\/p>\n Code ist nur schwer lesbar, wenn er keine Einrückungen enthält und alle Zeilen am linken Rand beginnen. Das Einrücken hierarchisch untergeordneter Elemente hat sich glücklicherweise fast überall durchgesetzt. Und falls nicht, gibt es geeignete Tools, um dies automatisiert nachzuholen. Ein Beispiel dafür ist der Indenter, den Sie unter http:\/\/www.oaltd.co.uk\/Indenter\/Default.htm<\/b> finden. Er bietet zahlreiche Optionen, um die Einrückungen zu definieren (siehe Bild 2). Neben den Einrückungen kann man Code auch durch Leerzeilen lesbarer machen. So könnte man beispielsweise den Block mit der Deklaration, das Instanzieren von Objekten, das Leeren von Objekten und sonstige logisch zusammenhängende Zeilen jeweils durch Leerzeilen voneinander trennen.<\/p>\n Bild 2: Optionen des Tools Smart Indenter, der Code automatisch einrückt<\/span><\/b><\/p>\n Auch überlange Zeilen sind manchmal ungünstig. Am besten bringt man die Zeilen auf eine maximale Länge, die der Breite des Codefensters Ihres Entwicklungsrechners entspricht.<\/p>\n Eine Variable in den Kopf eines Standardmoduls zu schreiben und als Public <\/b>zu deklarieren, ist bequem – immerhin steht diese Variable anschließend überall zur Verfügung. Aber weit gefehlt: Normalerweise handelt man sich mit so etwas leicht ärger ein.<\/p>\n Ausnahme sind einige wenige Anwendungsfälle, die einfach nicht ohne den Einsatz globaler Variablen auskommen. Der Grund für die Abneigung von Entwicklern gegenüber globalen Variablen ist der, dass man diese nicht nur von überall lesen, sondern auch von überall verändern kann. Und wenn man nicht genau aufpasst und beispielsweise die gleiche Variable einmal global und einmal innerhalb einer Prozedur deklariert, kann es schnell zu Problemen kommen: beispielsweise dazu, dass man in der Routine der vermeintlich global deklarierten Variablen einen Wert zuweist, diesen aber in einer anderen Routine, die tatsächlich auf diese globale Variable zugreift, nicht vorfindet.<\/p>\n Der Grund ist, dass VBA lokale Variablen immer bevorzugt behandelt und beim Vorkommen einer globalen und einer lokalen Variable die lokale Variable verwendet.<\/p>\n Dies gilt nicht nur für globale Variablen, sondern auch für solche, die modulweit gültig sind. Auch hier könnte eine innerhalb einer Routine im gleichen Modul deklarierte Variable gleichen Namens vorhanden sein, die zu Missverständnissen bei der Verwendung der Variablen führt.<\/p>\n Daher gilt prinzipiell folgende Regel: Deklarieren Sie Variablen immer für den kleinstmöglichen Gültigkeitsbereich. Wenn Sie eine Variable nur innerhalb einer Prozedur brauchen, dann hat ihre Deklaration nichts im Modulkopf zu suchen und sie sollte erst recht nicht global gültig sein.<\/p>\n Wenn Sie einmal eine Variable in mehr als einer Routine brauchen, die auch tatsächlich den gleichen Wert enthält oder auf das gleiche Objekt verweist, dann gibt es sicher auch eine Abhängigkeit zwischen den beiden Routinen, weil etwa die erste die zweite aufruft.<\/p>\n In diesem Fall verzichten Sie dennoch auf eine modulweite Deklaration der Variablen, sondern legen diese in der aufrufenden Routine fest und übergeben diese als Parameter an die andere Routine.<\/p>\n Diese Zwischenüberschrift besagt nichts anderes, als dass Sie auf einen modularen Aufbau bei der Programmierung von Routinen achten sollen. Weiter oben wurde erwähnt, dass die Aufteilung Ihres Codes auf die einzelnen Routinen ungünstig sein könnte, wenn Sie für eine Routine keinen einfachen Namen finden, der mit einem Substantiv und einem Verb erläutern kann, was in der Routine geschieht.<\/p>\n Klar ist es nicht einfach, einen einfachen Namen für eine Routine zu finden, die alle Felder eines Formulars validiert, den Benutzer fragt, ob dieser den aktuellen Datensatz auch wirklich speichern möchte, und anschließend noch eine Historie der geänderten Daten mit Informationen füllt.<\/p>\n Wenn Sie solche Routinen einsetzen, gliedern Sie den Code einfach in drei weitere Routinen aus, EingabeValidieren<\/b>, AenderungBestaetigen <\/b>und HistorieSchreiben<\/b>, <\/b>und rufen diese von der eigentlichen Routine aus auf, wobei Sie EingabeValidieren <\/b>und AenderungBestaetigen <\/b>als Funktionen auslegen, die das Ergebnis der Validierung und die Antwort des Benutzers zurückliefern und abhängig vom Ergebnis den jeweils nächsten Schritt aufrufen oder auch nicht.<\/p>\n Und die Routine, in der dies alles geschieht, nennen Sie einfach nur DatensatzSpeichern <\/b>(vorausgesetzt, der Name ist nicht ohnehin durch eine Ereignisprozedur wie Form_BeforeUpdate <\/b>vorgegeben).<\/p>\n Auf diese Weise haben Sie jedenfalls drei überschaubare Routinen, deren Wartung einfacher als bei einer einzigen, großen Prozedur sein dürfte. Außerdem können Sie diese leicht kopieren und an anderer Stelle mit ähnlichen Aufgaben einfügen und anpassen.<\/p>\n Manchmal enthält eine Zeile einen langen Ausdruck, der mehrere Funktionen miteinander kombiniert – beispielsweise DLookup <\/b>zum Ermitteln eines Wertes einer Tabelle, gepaart mit ein paar Zeichenketten-Funktionen, um das Ergebnis den Anforderungen anzupassen.<\/p>\n Solche Konstrukte lassen sich erstens schlecht debuggen und sind außerdem schon wenige Tage nach der Erstellung vermutlich nur noch schlecht nachzuvollziehen.<\/p>\n So etwas verhindert man in zwei Schritten: Erstens verteilt man die einzelnen Aufrufe auf mehrere Anweisungen – je eine pro verwendeter eingebauter Funktion.<\/p>\n Zweitens kann man die so erzeugten Zeilen im Sinne optimaler Codelesbarkeit in eine Funktion auslagern, deren Name kurz angibt, was diese für ein Ergebnis liefert.<\/p>\n Variablen sollten immer nur einem Zweck dienen beziehungsweise nur einen Wert enthalten.<\/p>\n Es ist zum Beispiel gefährlich, wenn Sie eine Zählervariable i <\/b>mehrmals innerhalb einer Routine verwenden.<\/p>\n Es könnte beispielsweise passieren, dass die Variable zwischendurch nicht initialisiert wird (etwa durch Setzen auf 0) und die Routine im weiteren Verlauf Fehler liefert.<\/p>\n Wenn Sie einer Variablen, wie oben empfohlen, einen eindeutigen Namen geben, der ihrem Zweck entspricht, werden Sie aber nur schwerlich in eine solche Situation geraten.<\/p>\n Eine Variable pro Aufgabe<\/p>\n Im Gegensatz dazu sollten Sie, in Ergänzung zum Abschnitt Sprechende Einzeiler<\/b>, so viele Variablen wie nötig verwenden, um Zwischenergebnisse zu speichern. Oft gibt es Probleme bei der Durchführung von Aktionsabfragen, deren SQL-Ausdruck im Code zusammengesetzt wird. Der Aufruf, zum Beispiel CurrentDB.Execute "INSERT INTO …"<\/b>, steht dann in einer Zeile und ist somit fast unmöglich zu debuggen. Hier verwendet man eine Variable namens strSQL<\/b>, der man zunächst den SQL-Ausdruck zuweist und die man anschließend wie folgt nutzt:<\/p>\n Auf diese Weise können Sie bei Problemen einen Haltepunkt setzen, strSQL <\/b>im Direktfenster ausgeben lassen, den Inhalt in die SQL-Ansicht einer neuen Abfrage eintragen und sich nach dem Ausführen eine exaktere Fehlermeldung und die fehlerhafte Stelle anzeigen lassen.<\/p>\n Von der unnötigen Verwendung des Variant-Datentyps haben wir schon oben abgeraten. Einer der Gründe war, dass er einfach überdimensioniert für manche Zwecke ist. Das gilt aber auch für andere Variablentypen.<\/p>\n Bei Datentypen wie Boolean, Datum, Text oder Währung ist die Auswahl nicht so groß, dass man Fehler machen kann, aber es gibt eine ganze Reihe numerischer Datentypen, die unterschiedlich große Wertebereiche abdecken:<\/p>\n Wenn Sie eine numerische Variable deklarieren, sollten Sie zuvor ermitteln, welchen Wert die Variable maximal annimmt, eine gewisse Sicherheit hinzurechnen und dann einen der oben genannten numerischen Datentypen auswählen, dabei aber beachten, ob es sich grundsätzlich um eine Gleitkommazahl oder um eine Ganzzahl handeln soll.<\/pre>\n Wenn Sie, wie oben empfohlen, Ihre Routinen modular programmiert haben, also jede Routine nur eine Aufgabe erledigen lassen und Variablen und Routinen sinnvoll benennen, brauchen Sie vermutlich so gut wie keine Kommentare mehr.<\/p>\n Es gibt zwei Möglichkeiten für die Übergabe von Parametern beim Aufruf von Routinen, die durch das Voranstellen eines der Ausdrücke ByVal <\/b>und ByRef <\/b>angegeben werden können.<\/p>\n ByVal <\/b>sorgt dafür, dass nur der Wert an die aufgerufene Routine übergeben wird. Wenn diese Routine dann änderungen an der Variablen, mit der dieser Wert übergeben wurde, vornimmt, wirken sich diese nicht auf die aufrufende Routine aus.<\/p>\n ByRef <\/b>übergibt keinen konkreten Wert, sondern einen Verweis auf die Speicheradresse des Werts. Wenn die aufgerufene Routine dem Parameter einen neuen Wert zuweist, dann arbeitet auch die aufrufende Routine mit diesem Wert weiter.<\/p>\n Wenn man dies nicht beachtet, sind unerwarteten Ergebnissen Tür und Tor geöffnet. Der Einsatz von ByVal <\/b>ist allerdings auch nicht ganz unproblematisch: Wenn Sie wie in den folgenden beiden Routinen den Inhalt einer Double<\/b>-Variablen an eine Routine übergeben, die eine Long<\/b>-Variable erwartet, erzeugt diese aus dem Double<\/b>-Wert einen Long<\/b>-Wert, in diesem Fall aus 1,5 <\/b>den Wert 2<\/b>.<\/p>\n Wenn Sie die Variable hier ByRef <\/b>übergeben, führt das zu einem Laufzeitfehler (Fehler beim Kompilieren: Argumenttyp ByRef unverträglich<\/b>).<\/p>\n Der Fehler ist verkraftbar, denn er lässt sich durch ändern des Datentyps entweder in der aufrufenden oder in der aufgerufenen Routine beheben. Dies dürfte viel schneller gehen als die Suche nach dem logischen Fehler, den obiges Beispiel liefert.<\/p>\n Die Gefahr, dass per ByRef <\/b>übergebene Werte ungewollt geändert werden und so zur aufrufenden Routine zurückgegeben werden, lässt sich mit einem Minimum an Disziplin erledigen.<\/p>\n Dazu legen Sie einfach eine temporäre Variable an, der Sie direkt zu Beginn den Inhalt der übergebenen Variablen zuweisen. Den Parameter verwenden Sie in der Folge gar nicht mehr, außer Sie wollen den enthaltenen Wert bewusst ändern:<\/p>\n Wer gut zu wartenden und lesbaren Code schreiben möchte, der überdies möglichst wenig fehler-anfällig sein soll, braucht keine dicken Bücher zu studieren. Dieser Beitrag zeigt einige einfache Möglichkeiten, die Qualität seines Codes zu verbessern.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662008,66042008,44000025],"tags":[],"class_list":["post-55000620","post","type-post","status-publish","format-standard","hentry","category-662008","category-66042008","category-VBA_und_Programmiertechniken"],"yoast_head":"\nstrText = "Beispieltext"<\/pre>\n
Set strText = CurrentDB<\/pre>\n
Option Explicit<\/pre>\n
![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Codieren-web-images\/pic001_opt.jpeg\")
<\/p>\nVariant vermeiden<\/h2>\n
\n
If IsNull(DLookup("ID", "tblKontakte", "_\r\n Nachname = 'Minhorst'") Then\r\n MsgBox "Kein Datensatz gefunden."\r\nEnd If<\/pre>\n\n
Public Sub TestAufEmpty(Optional var As _\r\n Variant)\r\n If IsMissing(var) Then\r\n MsgBox "Kein Parameter übergeben."\r\n End If\r\nEnd Sub<\/pre>\n
Dim var<\/pre>\n
Dim str1, str2 As String<\/pre>\n
Public Sub VarOderNichtVar()\r\n Dim str1, str2 As String\r\n Debug.Print "str1", VarType(str1), _\r\n TypeName(str1)\r\n Debug.Print "str2", VarType(str2), _\r\n TypeName(str2)\r\nEnd Sub<\/pre>\n
str1 0 Empty\r\nstr2 8 String<\/pre>\n
Ordnung muss sein<\/h2>\n
\n
Verwendung einer Namenskonvention<\/h2>\n
Dim objExcel As Excel.Application<\/pre>\n
Debug.Print Me!txtBeispiel.Value<\/pre>\n
Private Sub cmdTextfeldFuellen_Click()\r\n Dim txtBeispiel As Access.TextBox\r\n Set txtBeispiel = Me!txtBeispiel\r\n txtBeispiel = "Text"\r\nEnd Sub<\/pre>\n
Sprechende Bezeichnungen für Variablen und Routinen<\/h2>\n
Optische Aufbereitung des Codes<\/h2>\n
![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Codieren-web-images\/pic002_opt.jpeg\")
<\/p>\nGültigkeitsbereich von Variablen<\/h2>\n
Eine Routine pro Aufgabe<\/h2>\n
Sprechende Einzeiler<\/h2>\n
Eine Aufgabe pro Variable<\/h2>\n
CurrentDB.Execute strSQL<\/pre>\n
So klein wie möglich, so groß wie nötig<\/h2>\n
\n
-4,94065645841247E-324 für negative Werte; 4,94065645841247E-324 bis 1,79769313486232E308 für positive Werte<\/li>\r\n
Code kommentieren<\/h2>\n
ByVal und ByRef<\/h2>\n
Public Sub AufrufendeRoutine()\r\n Dim dblZahl As Double\r\n dblZahl = 1.5\r\n Debug.Print dblZahl\r\n AufgerufeneRoutine dblZahl\r\nEnd Sub\r\nPublic Sub AufgerufeneRoutine(ByVal lngZahl _\r\n As Long)\r\n Debug.Print lngZahl\r\nEnd Sub<\/pre>\n
Public Sub AufgerufeneRoutine(ByRef dblZahl _\r\n As Double)\r\n Dim dblZahlTemp As Double\r\n dblZahlTemp = dblZahl\r\n Debug.Print dblZahlTemp\r\nEnd Sub<\/pre>\n","protected":false},"excerpt":{"rendered":"