Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Excel 2013 VBA für Profis

Besser programmieren

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Ein paar wesentliche Tipps und Tricks zur Fehlervermeidung ersparen oft die mühsame nachträgliche Suche nach Fehlern. Vermiedene Fehler sind immer besser als korrigierte Fehler!

Transkript

Fehler sind eigentlich das, was man im Programm vermeiden möchte. Und es gibt tatsächlich Methoden, um das hinzukriegen. Die habe ich jetzt mal hier einfach als "Besser programmieren" betitelt. Es fängt zum Beispiel damit an, dass Sie einfach übersichtlicher schreiben, und zwar insbesondere, indem Sie sogenannte Code-Blöcke: Sub, End Sub; If, End If; With, End With; einrücken. Normaler Code, oder sagen wir besser schlechter Code, sieht so aus: Sie haben eine Prozedur und da wird dann gnadenlos alles hintereinander geschrieben. Für den Compiler ist das kein Problem. Der arbeitet das so ab, wie er das sieht. Und das ist im Prinzip alles hintereinander weg. Der versteht es technisch. Für Ihre Augen ist das völlig unbrauchbar. Da würden Sie gar nicht merken, ob hier genug End drin sind, ob dieses If mit einem End If, dieses With mit einem End With, und dieses If mit einem weiteren End If geschachtelt geschlossen wird. Wenn Sie den gleichen Code aber so schreiben, eingerückt, dann kann ich mit den Augen sofort drübergucken, Sub, End Sub. If, End If, passt; With, End If; If, End If. Ich habe also überall jeweils eingerückt mit der Tab-Taste. Das braucht ein bisschen Platz nach hinten, aber es ist unschlagbar für die Fehlerkontrolle und erspart Ihnen entsprechende Fehler. Also übersichtlich schreiben erstmal im optischen Sinne. Dann natürlich auch in der Benennung, das, was die Ungarische Notation ausmacht, nämlich Variablen zu benennen in einer Form, dass man dem Namen schon ansehen kann, was darin passiert. Solche Variablen sind Mist. Kann man nicht anders sagen. BeispielProzedur ist schonmal nichtssagend, aber i, j, und d sagen überhaupt nichts aus über den Sinn oder den Datentyp dieser Variable. Macht den Code völlig unlesbar, nicht nur für andere, sondern auch für Sie drei Wochen später. Wenn Sie stattdessen die Variablen so benennen, dann sieht man direkt, wenn man nur diesen Namen hat, es ist eine Integer-Variable und die wird zum Zählen benutzt. Diese Summe ist eine Double-Variable und das ist sinnvoll, damit die Summe auch Nachkommastellen hat. Und in diesem String steht der Name drin. Besser könnte man sogar noch formulieren: "strUserName", "strTabellenName" oder wenigstens "strTabName". Aber es ist deutlich lesefreundlicher und verbessert damit Ihren Code. Also übersichtlich schreiben in verschiedenen Varianten. Und auch bei den sprechenden Namen lässt sich noch einiges verbessern. Sehr beliebt sowas: myFunction (value) Das wird auch wenn Sie die automatisch erzeugen lassen, immer gern benutzt. Das (value), Dim s. Da weiß man nichts. Dieser Code taugt nicht mal was zu Testzwecken. Warum nicht so? Es ist natürlich ein bisschen länger, aber da weiß ich direkt, was passiert. Es ist eine Function, die eine Option ausliest, deren Namen ich hier nennen muss, anständig deklariert mit Datentyp, und auch den Rückgabewert hier als Datentyp. Und darin gibt es eine boolesche Variable, das hätte ich dem hier nicht ansehen können, die mitteilt, ob das Ding Erfolg hatte oder nicht und irgendwie ausgewertet wird. Ohne dass ich echten Code sehe, kann ich Ihnen anhand der Namen schon sagen, was passieren wird. Also, übersichtlich schreiben heißt besser programmieren. Und das bedeutet auch, Objekte komplett zu benennen. Das ist zwar länger. Diese Fassung ist kürzer. Da gibt es offenbar eine Variable AnzPokale. Daraus kann man noch erschließen, es ist die Anzahl der Pokale. So weit nicht schlecht, davon gibt es 9 Stück. Und: "Ich bin ein Beispieltext." Wer ein bisschen aufmerksam in VBA ist, weiß schon, da kann was nicht stimmen. Me kann kein Text sein. Also das ist zumindest merkwürdig und damit eigentlich auch schon Pfui. Und wenn Sie jetzt angucken, was da eigentlich wirklich stehen müsste, dann entdecken Sie, ach, AnzPokale ist gar keine Variable und deswegen gab es da vorneweg auch kein Präfix. Es ist offenbar ein Objekt in einem Formular zum Beispiel. Me ist das Formular. Darin gibt es ein Objekt AnzPokale, und dessen Value ist 9. Aha, das ist ja schonmal ganz was anderes, auch wenn Ihnen der Compiler das so durchgehen lässt. Hier weiß, ich muss mich in einem Formular befinden und so ein Objekt besitzen. Und dessen Value-Eigenschaft, die zugegebenermaßen die Standard-Eigenschaft ist, ist auf 9 gesetzt. Das ist weit verbreitet, muss ich leider sagen, aber schlampig. Das ist mit einer einzigen Zeile ganz viel verständlicher. Und auch hier, Me ist ein Formular. Ein Formular kann kein Text sein. Leider, muss ich an der Stelle mal leider sagen, ist Caption die Standard-Eigenschaft und deswegen wird dieses durchgelassen, diese falsche Schreibweise. Und, sage ich ganz ehrlich, nur deswegen weil VBA da sehr entgegenkommend ist in dieser Version. In VB ist das nicht so und in der nächsten Version können Sie nicht sicher sein, dass das noch so ist. Also korrekt weiß ich jetzt hier, es ist der Titel eines Formulars, der sich hier geändert hat, und damit ist das die bessere Schreibweise. Nennen Sie also Objekte komplett und das trifft vor allem hier solche, die scheinbar Variablen sind, aber in Wirklichkeit einen Objektnamen darstellen. Das dient dazu, Fehlerquellen massiv zu verringern, indem Sie einfach genau angeben, wen Sie meinen. Und das gilt auch für Variablen. Selbst wenn Sie die gut benannt haben, benutzen Sie die nicht mehrfach. Sowas zum Beispiel. Eine Variable intI, schwach benannt, sage ich mal freundlich, eine Integer-Variable. Und dann gibt es hier eine Schleife, die gilt von intI von 1 bis 10, wird also 10 Mal durchgelaufen und zeigt mit Debug.Print einfach nur den Wert an. Und wissen Sie, was hier passiert? Die wird 5 Mal durchlaufen, nicht 10. Beim ersten Schritt steht hier "Test 1". Dann wird intI auf 2 erhöht. Und die For-Next-Schleife erhöht es dann um einen Schritt und ist schon bei 3. Diese beiden, nämlich das For intI hier und das intI hier, die kommen sich ganz übel in die Quere. Ist also ein ganz übler Fehler, der nur deswegen hier so offensichtlich ist, weil ich draufzeige und Sie es gerade mal mit 4 Zeilen zu tun haben. Der ist meistens in so 20 Zeilenblöcken versteckt und heißt viel unauffälliger und Sie wundern sich nur, dass irgendwie nur jedes zweite Objekt angezeigt oder gelöscht wird. Also wenn Sie sowas machen wollen, eine Zahl hochzählen und eine andere anzeigen, dann benutzen Sie bitte auch zwei Variablen, die sich jetzt nicht mehr ins Gehege kommen, das sind unterschiedliche. Hier wird jetzt intZaehler von 1 bis 10 abgearbeitet und zufällig auch intI, aber beide gehen von 1 bis 10, und nicht 1, 3, 5, 7, 9. Und die 10 wird schonmal gar nicht erreicht, sondern umgangen. Also keine Variablen mehrfach benutzen, das verringert Fehlerquellen ganz deutlich. Und dazu gehört auch, möglichst selten öffentliche Variablen zu nutzen. Sehr verbreitet, auch weil die so schön praktisch sind. Einmal vorneweg irgendwie deklarieren, m_intZaehler As Integer. Das heißt, wo immer ich einen Zähler brauche, habe ich schonmal so eine, das sehe ich hier an meiner Vorsilbe "Modul", öffentliche Variable zur Verfügung. Und kann hier einfach diesen Zähler setzen. Sehr riskant, sehe ich gerade in langen Code-Zeilen sehr, sehr häufig, um da so ein bisschen Platz zu sparen. Besser ist, die gleiche Variable, und wenn es denn sein muss, in jeder Prozedur immer wieder zu deklarieren. Das ist schneller geschrieben als Sie später diesen Fehler suchen. wenn nämlich die eine Prozedur eine globale Variable ändert und die andere glaubt, dass sie noch den alten Wert hat. Das umgehen Sie mit lokalen Variablen, also nicht hier außerhalb der Prozedur ein Modul oder gar mit public-Datei, öffentlich, sondern wo immer es geht lokale Variablen. Auch das hilft sehr dabei, Fehlerquellen zu verringern. Und wenn es denn schon öffentliche Variablen gibt, dann sollten Sie die bitte auch kennzeichnen, so wie Sie das eben schon gesehen haben. Also nicht einfach intZaehler. Dann finden Sie nämlich irgendeine lokale Prozedur, die auch einen intZaehler irgendwie benutzt und ihn auf 99 setzt. Und Sie haben jetzt schlicht Glück, dass dieser Fehler hier keinen weiteren Schaden verursacht. Wenn diesen intZaehler nämlich auslesen und glauben, das sei die öffentliche Variable; nein, lokale gleichnamige Variablen überschreiben öffentliche. Also innerhalb der Prozedur ist diese nicht sichtbar, nicht erreichbar, nicht änderbar. Aber das müssen Sie erstmal bemerken. Also, wenn Sie darauf achten, öffentliche Variablen, entweder Modul öffentlich, zum Beispiel mit einem m_, oder Datei öffentlich, public, mit einem p_ zu kennzeichnen, dann ist jetzt klar, da ist ja die öffentliche Variable gemeint, weil hier nämlich ein m_ steht. Und die ist hier in diesem Zusammenhang überflüssig, aber ich habe ja auch nur kurzen Beispielcode. Aber jetzt ist völlig klar, welche von den Variablen gemeint ist. Und falls Sie jemals Dim m_, irgendeine Variable in einer Prozedur schreiben, muss es Ihren Augen wehtun, weil Sie gerade versuchen, einen öffentlichen Variablennamen lokal zu deklarieren. Das sollte dann direkt schon beim Schreiben auffallen. Es gibt noch mehr Möglichkeiten, Fehlerquellen zu verringern, indem Sie zum Beispiel Enumerationen einsetzen. Enumerationen erleichtern den Umgang zum Beispiel mit Select Case. Die beliebteste Art ist, eine Zeichenkette zu nehmen und dann zu fragen, ob darin ein "ohne", ein "mit", oder sagen wir, ein "spezial" steht. Das ist ein sehr hohes Risiko, denn irgendwann werden Sie das Wort "spezial" mit einem großen "S" schreiben und dann ist es nicht der dritte Fall, sondern ein vierter, der hier nicht genannt ist, weil Sie es anders geschrieben haben. Schreibfehler werden nicht erkannt, weil Zeichenketten nicht untersucht werden. Wenn Sie stattdessen eine Enumeration schreiben, bei der hier ein Enumerations-Name vereinbart wird, und dann eine beliebige Liste von Klartexten, nicht Zeichenketten, sondern echt geschriebenen Wörtern, groß/klein ist völlig wurscht. Dann stehen dahinter im Grunde Integer-Zahlen, 0, 1, und 2. Das macht Ihnen aber nichts. Und dann fragen Sie nicht die Zeichenkette, sondern eine Integer-Variable ab und vergleichen diese mit: Enumeration, Punkt, erster Wert. Und hier klappt eine Intellisense-Liste aus und bietet Ihnen direkt an, welche Varianten es gibt. Und wenn Sie eine ungültige nehmen, dann beschwert sich der Compiler und sagt, die kenne ich nicht. Hier wird sich der Compiler nicht beschweren, sondern Ihnen einfach kein Ergebnis liefern. Also auch damit lassen sich erheblich die Fehlerquellen verringern. Und damit zusammenhängend, wo ich hier nämlich gerade schon sagte, es gibt noch einen vierten Fall; wenn Sie sich vertippen, sollten Sie auch bestimmte Standardprüfungen vornehmen. Zum Beispiel bei Zeichenketten an Groß-/Kleinschreibung denken. Nicht einfach fragen, ob der Name in dieser Variable gleich "Hölscher" ist; das könnte nämlich einfach sein, dass jemand aus Bequemlichkeit kleingeschrieben hat; sondern diesen variablen Inhalt erstmal mit LCase, "lower case", in Kleinbuchstaben verwandeln und dann auch mit der kleingeschriebenen Variante Ihres Vergleichs vergleichen. Das ist also die richtige Variante, Groß-/Kleinschreibung in Normalfällen einfach ignorieren. Oder, das trifft diese Select-Case-Anweisung: bauen Sie immer den Else-Fall ein, der hier zum Beispiel leider übersehen worden ist. Wenn Sie zum Beispiel die Zahl 4 in intTest finden, dann gibt es die hier nirgends. Ist weder bei 2, 5, 7, noch bei 1, 3, 9 bis 11, noch 12 dabei. Die Zahl 4 löst keine Reaktion aus. Merken Sie aber nicht, weil eben nichts passiert. Wenn Sie jedoch genau eine Zeile mehr schreiben, Case Else: MsgBox "Fehler", und dann meistens irgendein Hinweis: "Rufen Sie Ihren Admin an, es ist der Fehler 1793 aufgetreten." Dann wissen Sie, ups, diese Meldung sollte eigentlich nie kommen. Warum kommt die? Welcher Wert steht dadrin? Aha, 4. Habe ich wohl vergessen. Dann meldet sich automatisch Ihr Programm und sagt, hier gibt es einen Fall, an den du nicht gedacht hast. Also Fehlervermeidung heißt eigentlich ganz kurz: Schreiben Sie übersichtlich. Verringern Sie dadurch die Fehlerquellen. Und nehmen Sie bestimmte Standardprüfungen vor. Dann sind die meisten Fehler eigentlich schon direkt geheilt. Es gibt noch genug andere, aber hier die überflüssigen Fehler sozusagen, die können Sie damit vermeiden.

Excel 2013 VBA für Profis

Nutzen Sie die Möglichkeiten der Programmiersprache VBA in Excel 2013, um eigene Dialoge zu erstellen, auf andere Arbeitsmappen zuzugreifen und wichtige Funktionen einzusetzen.

4 Std. 59 min (53 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!