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 2016 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

Um Fehler zu vermeiden, müssen Sie eigentlich nur besser programmieren. Das sagt sich natürlich jetzt relativ locker und gefällig, aber es gibt tatsächlich Methoden, um einen besseren Programmierspiel zu haben und damit auch weniger Fehler zu erzeugen. Die überflüssigen Fehler sind diejenigen, die man vermeiden kann. Es fängt damit an, dass Sie übersichtlich schreiben. So selbstverständlich wie ich das jetzt sage, ist es offenbar nicht. Ich sehe ganz viel Code, wo das nicht eingehalten wird. Es beginnt damit, dass Sie Code-Blöcke haben. Also Sub, End Sub, If, End If, With, End With usw. auch einrücken. Das also solche Prozeduren, wo alles hier vorne schön hintereinander, in einer Zeile steht, vermieden werden. Dem Compiler ist das egal, der kann das verstehen. Aber wenn Sie drübergucken und das lesen wollen, ist es völlig unbrauchbar. Wenn Sie es stattdessen einrücken, dann können Sie per Augenschein sofort sagen, Sub, End Sub - passt. If, End If - passt auch, With, End With - passt. Und hier ist das eingeschachtelte If, End If - alles wunderbar. Und durch dieses Einrücken, müssen Sie nur grad hier mit den Augen lang gehen und sehen sofort, wenn hier eine Lücke ist. Wenn Sie sozusagen nicht wieder mit der Treppe zurückkommen. Dies ist also die bessere Variante, weil sie viele, viele überflüssige Fehler erspart, die man durch bloßes Draufgucken erkennen würde. Und übersichtlich schreiben, meint nicht nur das Einrücken, sondern auch das Benennen. Ich kann Ihnen dringend nur die Ungarische Notation empfehlen, die vor dem eigentlichen Namen immer so einen Präfix, für den Datentyp, oder den Objekttyp nennt. Also, so ein Code wie hier ist völlig unbrauchbar. Die beliebten Variablennamen a, b, c, i, j, d oder sonst was sind völlig nichtssagend. Häufig wird auch Dim d As Double geschrieben. Dann soll man raten, dass d eine Double Variable ist, oder Dim d As String. Hilft Ihnen aber trotzdem nicht weiter. Erstens gehen ihnen sofort die Buchstaben aus. Dim i As Integer, aber danach kommt oft Dim j As Integer. Also wenig aussagekräftig. Sollten Sie sich auf gar keinen Fall angewöhnen. Anständigerweise heißen Variablen so. Also intX, dann weiß ich, es ist eine Integervariable und die zählt irgendwas. Ich weiß, es ist eine Double Variable, die eine Summe bildet. Hier weiß ich, es ist ein String, eine Zeichenkette, aber ich könnte vielleicht sogar noch verbessern, dass es nicht irgendein Name ist, sondern vielleicht Benutzername, Tabellenname oder sonst was. Also diese Variante ermöglicht schon durch bloßes Hingucken, auf die Variablennamen, zu vermuten, was sie tun sollen. Wenn dann irgendwo steht intX="Text", dann können Sie schon an der Zeile sehen, das kann überhaupt nicht funktionieren. Das Übersichtlich-Schreiben empfiehlt also: Sprechende Namen. Diese Variablen wie As, oder auch Funktionsbezeichnungen, wie myFunction, die relativ häufig benutzt werden, sind unbrauchbar. Schreiben Sie, auch wenn das mehr Aufwand ist - sowas. Dann können Sie direkt sagen, "Aha, diese Function ließt also eine Option aus. "Sie möchte einen Namen übergeben bekommen, der ist im Datentyp String und die hat den Rückgabewert Variant." Und dieses Dim s sollte offensichtlich eine Boolean-Variable sein, die irgendwie den Erfolg mit Ja oder Nein misst. Obwohl der eigentliche Code fehlt, kann ich an diesem sogenannten Prozedurrumpf plus hier einer Variablen, schon sehen, was gemeint ist. Auch das erspart die Fehlersuche. Nicht nur im eigenen Code, sondern vor allem im fremden Code. Und wenn Sie schon übersichtlich schreiben und Variablen komplett benennen, dann sollten Sie das auch mit Objekten machen. Hier zum Beispiel lese ich auf Anhieb, "Aha, es gibt hier eine variable Anzahl Pokale." Das ist ja schonmal ganz erfreulich und der ist auf neun gesetzt. Sehr merkwürdig ist diese Variable Me, die einen String zugewiesen bekommt. Denn ich weiß, Me ist eine Objektvariable, in einem Formularmodul und der kann ich keine Zeichenkette zuweisen. Also, da kann irgendwas nicht stimmen, aber das ist ganz klar und trotzdem ist es falsch. Wenn ich nämlich dann wirklich in den Code gucke, entdecke ich AnzPokale ist gar keine Variable. Das ist innerhalb eines Formulars die Bezeichnung eines Steuerelements und dessen Wert. Da könnte vielleicht sinnvollerweise so was wie Edit AnzPokale stehen oder so. Da kann ich sofort im Code sehen, das ist das Hauptobjekt, ich befinde mich offenbar in einem Formular, darin ein Steuerelement und dessen Eigenschaft ändere ich. Und auch hier, Me hat die Standardeigenschaft Caption, aber das müssen Sie nicht ausreizen, sondern lieber ehrlich hinschreiben. Das erspart einem viel Fehlersuche und deswegen die Ausführlichkeit, der bisschen Mehraufwand beim Vorherschreiben erspart Ihnen viel Fehlersuche hinterher. Und darum geht es eigentlich vor allem: Fehlerquellen zu verringern. Es gibt genug Fehler, die sowieso auftreten, dann müssen Sie sich nicht noch zusätzlich, mutwillig welche dazubasteln. Zum Beispiel, Variablen sollten Sie nicht mehrfach nutzen. AUch das ist sehr beliebt, so wie hier: Sie haben eine Variable deklariert und weil Sie keine Lust haben, noch eine zweite zu deklarieren benutzen Sie die einfach. Hier ist das natürlich extrem kurz, da stehen meistens 10-20 Zeilen zwischen und Sie sagen, "Oh, da brauche ich mal eben für irgendeine eine Ansicht, noch eine Zahl, die ich dann hochzählen kann." Was tatsächlich passiert ist, dass nicht von 1-10, zehn Durchläufe in der For-Next-Schleife sind, sondern in der ersten Schleife, wenn der Int I Wert auf 1 steht, wird hier Test 1 angezeigt, dann wird der Int I Wert um einen erhöht, auf 2, dann kommt die For-Next-Schleife, erhöht ihn wieder auf 3, das heißt faktisch kommen hier nur noch fünf Durchläufe an. 1, 3, 5, 7, 9. Das war's dann. Weil Sie die Zählervariable hier irgendwo im Code, innerhalb der Schleife, mutwillig geändert haben. Und noch schlimmer ist, wenn sie -1 zählen, dann haben Sie nämlich eine Endlosschleife. Das muss man erstmal hinkriegen mit For-Next, weil der Zähler 1, um 1 verringert wird auf 0. Jetzt wieder erhöht, steht wieder bei 1. Sie sehen also ewig und drei Tage lang die 1. Auf gar keinen Fall Variablen mehrfach benutzen. Gönnen Sie sich eine mehr, dass ist natürlich ein Tick mehr Aufwand, hier eine Zeile mehr letzten Endes, aber dafür läuft ihr Code und Sie haben keine merkwürdigen Fehler, die Sie irgendwie suchen müssen. Die sind ganz übel, weil sich ihr Code merkwürdig verhält und liegen selten so eine Zeile hinter der nächsten, dass man sie sofort sehen kann. Die Fehlerquellen lassen sich auch an anderen, ähnlichen Stellen verringern, indem Sie möglichst selten öffentliche Variablen nutzen. Auch das verführt dazu, die versehentlich von anderen Stellen aus zu ändern. Typischerweise sieht das so aus. Ich sehe das an meiner Benennung. Das ist ja sozusagen eine extra Erweiterung der ungarischen Notation. m_ sagt mir, "Aha, Modul-öffentlich". Und hier in der Beispielprozedur habe ich die jetzt geändert. Hoffentlich mit Absicht, denn jede andere Prozedur darf die genauso ändern. Und wenn ich mich irgendwo drauf verlasse, dass sie einen bestimmten Wert hat, oder jemand zuletzt geändert hat, kann ich das "Modul-öffentlich" nicht unbedingt sicherstellen. Wenn möglich, vermeiden. Besser ist es, eine lokale Variable zu benutzen, die nur innerhalb der Prozedur ändert und sichtbar ist. Und damit weiß ich auch sehr genau, wer sie überhaupt ändern darf. Nämlich nur diese Prozedur. Das ist, wenn es irgendwie möglich ist, die sinnvollere Variante. Natürlich brauchen Sie auch mal öffentliche Variablen. Und dann sollten Sie möglichst nur "Modul-öffentliche" und nicht auch noch "Public-Datei-öffentliche" benutzen. Und wenn Sie öffentliche Variablen benutzen, dann sollten Sie die entsprechend kennzeichnen. Sehr häufig sehe ich so was. Da wird eine "Modul-öffentliche" Variable nur so geschrieben. Und irgendwo, hundert Zeilen tiefer, steht eine lokale Variable. Meistens ist die sogar noch kürzer, Int I oder gar nur I. Das heißt, weil das so schön schnell geht und Sie das immer I nennen, sagen Sie auch hier I, das wichtigste Problem ist, die sind gleichnamig. Und hier kann ich Ihnen ganz klar sagen, was Sie ändern: Die lokale Variable. Sobald eine lokale Variable gleichnahmig mit einer öffentlichen ist, überdeckt sie diese. Das heißt, innerhalb der Prozedur ist das garantiert die lokale Variable. Das können Sie nur leider nicht mehr sehen. Das muss man wissen. Also hochriskanter Code, auch weitest verbreitet. Anständigerweise sieht es so aus. Öffentliche Variablen werden gekennzeichnet. Bei mir die "Modul-öffentlichen" mit m_ und die "Public-Datei-öffentlichen" werden mit p_ gekennzeichnet. Und sobald ich eine lokale Variable deklariere, darf da weder m noch p davorstehen. Und hier ist ganz klar, dass ich die öffentliche Variable meine und das sehe ich am Variablennamen. Wenn Sie solche Konstruktionen, wie hier haben, sollten Sie einfach alle diese Variablen automatisch umbenennen, mit "Bearbeiten Ersetzen" überall m_ IntZaehler und dann entdecken Sie plötzlich im Code, dass eine lokale Variable als Dim m_ Zaehler deklariert wurde und dann wissen Sie, "Achtung, die war gleichnamig. Hochriskant." Also "Modul-öffentliche" kennzeichen, "Public-Datei-öffentliche" natürlich auch und die lokalen nicht. Wir können die irgendwie auch noch zusätlich kennzeichnen, aber die sollten häufiger sein und die eher selten. Also unterscheiden Sie auch im Variablennamen unbedingt, welchen Sichtbarkeitsbereich so eine Variable hat. Also Modul oder Datei. Öffentlich gegen lokal. Und Sie können solche Fehlerquellen noch weiter verringern, indem Sie Enumerationen einsetzen. Auch die helfen Ihnen, merkwürdigen Code zu vermeiden. Typischerweise wird so etwas so gelöst, wenn Sie sagen, ich habe verschiedene Arten von... sagen wir, Datentypen, dann erfinden Sie eine Stringvariable StrArt und übergeben dieser einen Text. Der heißt dann, "ohne", "mit" oder "spezial" beispielsweise. Und sobald Sie sich verschreiben, wenn Sie den Parameter übergeben, weil Sie nicht mehr wissen, wie er heißt und nur noch ungefähr im Kopf haben, schreiben sie einmal "Spezial" groß. Dann haben Sie schon verloren. Das ist nicht identisch mit diesem Wort. Das bedeutet also, der Code, den Sie eigentlich gerne hätten, wird nie ausgeführt. Das ist riskant. Weit verbreitet, aber nicht in Ordnung. Stattdessen sollten Sie ein Enumeration anlegen. Irgendwo. Typerscherweise mit Public Enum, in einem öffentlichen Modul, wo diese drei Wörter als konstanten Namen im Grunde abgelegt sind. Deren Schreibweise gilt, die weiß auch der Editor und Sie beziehen sich jetzt nicht mehr auf eine Stringvariable oder Parameter, sondern auf eine von diesem Datentyp enmArt. Ich konstruiere hier immer so eine Bezeichnung Enumeration, enm davor, und das, was hier steht, wird hier als Präfix irgendwie benutzt. Da kann ich sagen, dieser Wert muss einer von diesen dreien sein. Und der Editor bietet an dieser Stelle direkt mit IntelliSense eine Aufklappliste, da stehen die drei drin, die können Sie also jederzeit beim Programmieren sehen und einen anklicken. Und wenn Sie einen Vierten erfinden, dann gibt es sofort eine Fehlermeldung, die dann sagt, "Den kenne ich nicht". Also, das bisschen Mehraufwand für eine Enumeration, macht nicht nur das Programmieren schneller, weil Sie diese Wörter nicht mehr im Kopf haben müssen, sondern auch fehlerfrei, weil es nur noch diese Wörter erlaubt gibt. Daher sollten Sie auch Standard-Prüfungen vornehmen, wenn Sie solche Wörter überhaupt untersuchen, wenn in irgendeiner Form Strings verglichen werden, denken Sie an Groß- und Kleinschreibung. Schreiben Sie also nie einfach, ob der Name gleich irgendwas ist. Die Select-Case-Struktur war ja nur dasselbe in Grün. Denn es könnte sein, dass sich mein Name grade klein schreibe. Unnötige Fehlerquelle, sorgen Sie direkt dafür, dass die Eingabe im LCase in Kleinbuchstaben umgewandelt wird und natürlich, dass das Vergleichswort auch in Kleinbuchstaben geschrieben wird und dann sind Sie sehr viel fehlerärmer, indem Sie nicht suchen müssen, wie hat derjenige das gerade geschrieben. Andere Standard-Prüfungen bestehen darin, dass Sie immer einbauen, was sonst noch passieren könnte. Der Else-Fall. Hier zum Beispiel haben wir eine Select-Case-Struktur, die kriegt eine Integerzahl und lassen wir einfach mal die Zahl 4 sein, dann ist die weder hier, noch hier, noch größer 12. Und die Zahl 4 erzeugt also keine Reaktion. Es kann sein, dass Sie das so wollen, aber das ist meistens nicht so. Meistens ist das vergessen worden. Und wenn Sie das so erweitern, um diese eine Zeile, dann meldet sich im Falle 4, der Else-Fall und sagt "Fehler". Da steht natürlich im normalen Leben mehr drin, da würde ich dann zum Beispiel formulieren, "Unbekannte Testzahl" und dann kann man die noch anzeigen, "Bitte wenden Sie sich an den Programmierer", oder sowas. Und vielleicht Sie sich selbst noch eine Fehlernummer da rein, so dass Sie wissen, ich muss im Code nur diese Fehlernummer sofort suchen und weiß, was wo passiert ist. Also auch wenn Sie der festen Überzeugung sind, alle Fälle hier abgedeckt zu haben, bauen Sie trotzdem einen Else-Fall rein. Normalerweise wird er nicht erscheinen, aber wenn doch, wissen Sie genau, was und wo passiert ist. Kurz gesagt, die Fehlervermeidung, nämlich die Vermeidung überflüssiger Fehler. Es gibt genug andere, da müssen Sie sich nicht auch noch die dazufügen. Die Fehlervermeidung besteht vorallem darin, dass Sie übersichtlich schreiben, sowohl in der Bennenung als auch im Einrücken zum Beispiel, dass Sie Fehlerquellen verringern, indem Sie bestimmte Schreibweisen bevorzugen und Standard-Prüfungen vornehmen. Also faktisch immer den Else-Fall einbauen. Und dann sind eigentlich die meisten Fehler schon vermieden.

Excel 2016 VBA für Profis

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

5 Std. 52 min (55 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.01.2017

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!