»Code lesen ist ja manchmal auch so das >aus Innereien wahrsagen< unserer Zeit.«
Rin Räuber I @rinpaku, Twiner, 10. Mai 2013
Häufig ist es leichter, Code zu schreiben, als ihn zu lesen. Das hat damit zu tun, dass wir beim Schreiben von Code bereits ein geistiges Modell des Programms im Kopf haben, das wir dann nur noch aufschreiben. Dieses »nur Aufschreiben« ist schon schwierig genug. Um aber Code, insbesondere fremden, lesen und verstehen zu können, muss man das geistige Modell im Kopf des Entwicklers durch Lesen des Produkts rekonstruieren, und das ist sehr viel schwieriger. Selbst wenn man gut geschriebenen Code liest, muss man gleichzeitig die Syntax verstehen und das Verhalten des Codes als Ganzes im Hinterkopf behalten können, während man die Details einer Funktion nachzuvollziehen versucht. Das fällt nicht nur Einsteigern schwer.
Dennoch ist es wichtig, gelegentlich den Code anderer Leute zu lesen, weil es einem dabei hilft, zu einem besseren Programmierer zu werden. Ganz häufig machen andere Programmierer Dinge anders, und zwar besser. Da wir nicht immer die Gelegenheit und/oder den Mut dazu haben, andere zu einem konkreten Problem auszufragen, ist es ein guter Ersatz, ihre Problemlösungen nachzulesen.
Es ist normal, gegenüber dem Lesen von Code einen gewissen Widerwillen zu empfinden. Das Gehirn der meisten Menschen sträubt sich gegen übermäßige Anstrengung und findet, ein wenig Zerstreuung sei harter Arbeit durchaus vorzuziehen. Wozu unverständ-. Kii Code lesen und verstehen, wenn man in der gleichen Zeit Katzenbildchen und Rage-Comics betrachten kann?JeffAtwood, der Autor des Blogs Coding Horror, schreibt: Keiner liest aus Spaß an der Freude fremder Leute Code - ich lese noch nicht mal meinen eigenen gerne. Die Vorstellung, dass man sich gemütlich in einem Ledersessel nieder-
lässt, um sich bei einem guten Gläschen Brandy mit fremdem Sourcecode einen schönen Leseabend zu machen, ist absurd.«1
Allerdings widersprechen ihm nicht wenige andere Programmierer, die das gar nicht so absurd finden oder sogar beim Lesen eleganten Codes Befriedigung empfinden. Vielleicht geht es Ihnen wie Jeff Atwood. Vielleicht gehören Sie auch zur zweiten Gruppe, oder vielleicht werden Sie irgendwann später einmal ein Mensch werden, der Code zum Vergnügen liest. Versuchen Sie jedenfalls für den Anfang, folgenden Deal mit Ihrem Gehirn zu schließen: Sie lesen wenigstens gelegentlich längere Codepassagen und denken darüber nach, ohne dass Ihre bequemeren Persönlichkeitsanteile Sie immer wieder in ein anderes Browserfenster zerren wollen.
Falls Sie Widerwillen beim Lesen von Code empfinden, gehen Sie ehrlich damit um: Nein, es liegt nicht am Code. Es liegt auch nicht an Ihrer Intelligenz. Es liegt nur daran, dass Sie beim Betrachten von Fremdcode nachdenken müssen. Das ist okay, denn Nachdenken macht Arbeit und man darf es jederzeit verweigern. Aber man sollte es mit der Begründung tun >>Ich will darüber jetzt gerade nicht nachdenken«, und nicht mit der Begründung »Dieser Code ist so hässlich« oder »Ich bin einfach zu dumm«.
Ein grundsätzlicher Unwille, auch nur das kleinste Stück Fremdcode zu lesen, kann Sie auch dann vom Dazulernen abhalten, wenn Sie eigentlich gerade etwas herausfinden wollen. Man betrachtet eine Bibliothek, die man einsetzen möchte, oder man liest ein an sich informatives, aber mit Codebeispielen durchsetztes Buch. Hat man gar keine Übung im Codelesen, macht man nur schaudernde Geräusche und blättert weiter.
Wenn Sie sich in eine neue Sprache oder eine neue Technologie einarbeiten wollen, dann ist es grundsätzlich eine gute Idee, existierenden Code zu suchen und zu lesen, um sich ein Bild davon zu machen, wie die üblichen Programmierkonventionen aussehen. Dabei müssen Sie den Code nicht vollständig und in aller Tiefe verstanden haben - häufig ist es sogar nützlich, an der Oberfläche zu bleiben. Haben Sie die Sprache oder die Funktionen der Bibliothek so weit begriffen, dass Sie sie mechanisch nachahmen können, sind Sie schon kompetent genug, um die ersten hässlichen Versuche zu starten. Der Rest ergibt sich dann durch Versuch und Irrtum und weiteres Nachlesen.
Sie können auch durch äußere Umstände dazu gezwungen sein, sich mit fremdem Code zu beschäftigen, und dann ist es gut, wenn Sie schon Erfahrung mit dem Codelesen haben. Für Programmierer, die in Firmen angestellt sind, aber auch für viele Nichtprogrammierer, die an ihrem Arbeitsplatz gelegentlich mit kleinen Skripten und Programmen hantieren müssen, ist es recht üblich, den Code von Vorgängern oder Kollegen überarbeiten zu müssen - und das geht nicht, ohne ihn gelesen und einigermaßen verstanden zu haben.
Selbst wenn Sie nur aus Spaß und ganz alleine vor sich hinprogrammieren, können Sie in die Verlegenheit geraten, sich eingehend mit fremdem Code beschäftigen zu müssen. Es 1 ist heute selbst für einfache Programme üblich, auf Fremdcode aufzubauen. Sprachen bringen ihre grundlegenden Bibliotheken mit, und Anwendungsumgebungen wie das Web oder Mobile Devices sind ohne die Verwendung eines Frameworks kaum zu programmieren. Immer mehr dieses Fremdcodes ist Open Source, was es möglich macht, in die Quellen zu schauen. Und Open Source-Code wird häufig nicht unbedingt mit einer gut ausgebauten Dokumentation geliefert, auch wenn PHP und jQuery zwei beeindru-kende Ausnahmen darstellen. Spätestens, wenn Sie bei einem hartnäckigen Fehler nicht weiterkommen und in einem Forum für Programmierer nachfragen, wird die Antwort Code enthalten, den Sie verstehen müssen.
Auch wenn Sie etwas geschrieben haben, was irgendjemand außer Ihnen selbst nutzt -und das kann schon drei Wochen nach Ihrer Lektüre von »LEGO-Roboter bauen und programmieren« der Fall sein -, kommen Sie manchmal nicht daran vorbei, Fremdcode zu lesen. Nämlich dann, wenn Ihr Code bei jemand anderem nicht das tut, was er soll. In diesem Moment sind Sie selbst für alle Bestandteile verantwortlich, auch für die, die Sie gar nicht selbst geschrieben haben. Sie können sich nicht damit herausreden, dass Sie afür nicht zuständig sind. In dem Moment, in dem Sie der Welt Ihren Code überlassen haben, haben Sie implizit die Verantwortung für ihn übernommen. Es ist so ähnlich wie mit dem Kinderkriegen: Man kann sich zwar nach einer Weile davonschleichen, aber anständig ist das nicht.
' häufig Code liest, achtet beim Schreiben mehr auf Lesbarkeit, denn er hat leichter n schwerer verständlichen Code kennengelernt und sich schon in der Rolle desjenigen idem der den fremden Gedanken folgen muss. Und wer ein paarmal über schlechte aspiele, unverständliche Einrückungen und veraltete Dokumentation geflucht hat, nkt vielleicht beim Schreiben eigenen Codes eher an den Leser: »Code muss lesbar sein, Jas hat für mich inzwischen die höchste Priorität. Lesbarkeit ist wichtiger als Geschwin-_aai und fast so wichtig wie Korrektheit. Aber meiner Meinung nach bekommt man korrekten Code sowieso am ehesten, indem man lesbaren Code schreibt.«2 Für Anfänger s§: das eine gute Nachricht, denn es ist leichter, leserlichen Code zu schreiben als hochop-• mierten Code.
Ein paar Ratschläge zum erfolgreichen Lesen fremden und eigenen Codes finden Sie im toi genden Abschnitt.
•■Eine Stunde Code lesen kann einem eine Minute Lesen in der Dokumentation ersparen.«
Diomidis Spinellis: »Code Reading<<
palls es Dokumentation zum Quellcode oder dem Programm gibt, an dem Sie arbeiten, ai Sie die zuerst. Das spart viel Zeit beim Codelesen, denn die Dokumentation liefert
Ihnen einen Überblick über die Funktionsweise des Programms und darüber, wie es typischerweise verwendet wird. Diese Konzepte müssten Sie sich sonst erst mühsam aus dem Code erschließen.
Insbesondere wenn unbekannte Bibliotheken eingebunden werden, reicht es häufig aus, die Dokumentation zu lesen. Im Quellcode verirren Sie sich nur (Bibliothekscode ist häufig ziemlich groß) und verlieren das eigentliche Ziel, die Bibliothek nur zu verwenden, schnell aus den Augen. Bibliotheken sind Code, der für die Wiederverwendung in fremden Projekten geschrieben ist. Er sollte eine übersichtliche Schnittstelle mitbringen und vom Benutzer (also dem Programmierer) keine Beschäftigung mit den Interna erwarten. Programmbibliotheken bringen in der Regel auch Dokumentation mit.
Was man beim Lesen der Dokumentation weniger gut lernt, sind die Zusammenhänge: Wie kann man die Rückgabewerte einer Funktion sinnvoll für den Aufruf einer anderen verwenden, welche Best Practices gibt es in der Sprache, wie kann man eine Bibliothek in ein lauffähiges Programm einbinden? Eine solche Übersicht gewinnen Sie am besten, indem Sie Beispielcode lesen - der wird von manchen Sprach- oder Bibliotheksentwicklern bereitgestellt. Zu etwas bekannteren Programmen und Bibliotheken gibt es auch immer Foren, Blagbeiträge und/oder Codebeispiele (»Snippets«) im Web. Wenn Sie überhaupt nichts finden, das dokumentiert, wie der Code verwendet werden soll, dann sollte Sie das misstrauisch machen - die Bibliothek ist entweder noch sehr jung und damit möglicherweise auch noch unausgereift, oder keiner verwendet sie. Beides ist keine Schande, aber ungünstig für Sie, da Sie vermutlich hin und wieder die Unterstützung anderer Nutzer benötigen werden.
Anfänger haben dabei einen Vorteil: Sie müssen sich nicht überlegen, ob der Code, den User in irgendeinem Forum veröffentlichen, gut oder schlecht ist. Er ist wahrscheinlich jedenfalls nicht schlechter als ihrer. Solange Sie sich nicht nur auf den Code einer einzelnen anderen Person verlassen, werden Sie mittelfristig besser werden, selbst wenn Sie sich gelegentlich Unsitten oder suboptimale Lösungen abschauen.
Wenn Sie gern mit Papier arbeiten, kann ausgedruckter Sourcecode die Darstellung auf dem Monitor ergänzen. Auf Papier schreiben sich schneller Kommentare, Ausgedrucktes ist für manche Menschen leichter zu lesen als der Bildschirminhalt und man kann zwei Seiten nebeneinander legen, während man auf dem Monitor den Code editiert. Sie brauchen sich dabei nicht blöd vorzukommen, auch ausgewachsene Programmierer verfahren so: »Wenn ich ein System durchschauen will, das so eng verzahnt ist, dass ich alles lesen muss, um ein bestimmtes Element zu verstehen, das ist ein Albtraum ... Meistens drucke ich alles aus, setze mich mit dem Ausdruck auf den Boden und schreibe Notizen dran.«3
Diese Methode ist vor allem dann interessant, wenn Sie keine IDE einsetzen, denn moderne Entwicklungsumgebungen stellen viele Hilfen zum Verständnis des Codes zur Verfügung, deren man sich durch einen Ausdruck beraubt. Außerdem machen lange Namen den Text oft so breit, dass er nicht mehr auf die Seite passt, und durch Umbre-hen geht die optische Struktur verloren. Bei größeren Projekten stößt das Ausdrucken sowieso an Grenzen: Wenn Sie eine umfangreiche Bibliothek ausdrucken, bekommen Sie einen 500-Seiten-Stapel in die Hand. Das ist zum einen unökonomisch, zum anderen werden Sie sich in einem solchen Wust nicht zurechtfinden. Drucken Sie daher selektiv, zum Beispiel den Verzeichnisbaum des Projekts, damit Sie die Dateien, die dazugehören, immer im Blick haben. Oder die API, damit Sie sehen, welche Funktionen zur Verfügung ■•dien. Wenn Sie ein Programm und keine Bibliothek lesen wollen, dann drucken Sie zunächst den Einstiegspunkt (main() bei C-ähnlichen Sprachen, also etwa PHP, Perl, Java, JavaScript, C++ oder C#) und die Funktionen aus, die Ihnen interessant erscheinen.
Die 1 980er Jahre waren die große Zeit der schematischen Programmdarstellung. Damals \aren Struktogramme4 und Flowcharts4 zur Visualisierung des Programmablaufs sehr eliebt. Diese Darstellungsarten haben heute ein wenig an Bedeutung verloren, obwohl sie eine gute Möglichkeit darstellen, das Buchstabensuppenproblem zu entschärfen: Sie "leten eine weniger abstrakt anmutende Sicht auf das Programm, die nicht durch Syntaxdemente wie { oder ] verstellt wird.
E • reicht völlig aus, ein Blatt Papier zu nehmen und mit Kästchen, Pfeilen und Kreisen . r Programmablauf aufzuzeichnen - welche genauen Figuren bei Flowcharts für was 't v hen, ist unerheblich, denn Sie wollen diese Darstellung nur für Ihr Verständnis des Programms erzeugen. Falls Sie viel Zeit haben oder sich dringend vor wichtigeren Aufgaren drücken müssen, können Sie sich auch in die grafische Modellierungssprache UML einarbeiten und damit viel professioneller als mit Stift und Papier die statischen und ■namischen Strukturen von Programmen abbilden.
Außerdem gibt es erste Ansätze für Visualisierungstools, die den Code automatisch in •;ner besser verständlichen Form darstellen. Wenn Sie mit einer Suche nach code visua-:::.iition im Zusammenhang mit der Programmiersprache Ihrer Wahl ein Tool finden, u-1it dem Sie arbeiten können und wollen, brauchen Sie die Filzstifte nicht auszupa--ken. Und wenn Sie den Code eines professionellen Projekts studieren, kann es sein, :.rs es bereits irgendwo die allerschönsten Diagramme gibt, die Sie bloß noch ausfind ig machen müssen.
Wenn die Dokumentation nicht ausreicht oder es gar keine gibt, sollten Sie sich zunächst anhand der Organisation des Codes eine grobe Übersicht verschaffen. Wie viele Dateien gibt es? Was sagen deren Namen über ihre Funktionen aus?
Eine Datei, die so heißt wie das Projekt, enthält meist den Start des Programms und seine wichtigsten Bereiche. Hier verbergen sich die main()-Methode oder - im Fall einer Bibliothek - die Funktionen, die für Sie als Anwender der Bibliothek besonders interessant sind. Sie sollten daher zunächst diese Datei untersuchen, während alles, was »helper« oder »util« im Namen trägt, für den Überblick eher unwichtig ist.
Ein Texteditor mit Code Folding hilft ungemein dabei, die Grobstruktur eines Codemoduls zu verstehen. Code Folding bedeutet, dass man Teile des Codes vorübergehend ausblenden kann, so dass zum Beispiel nur noch die äußerste Einrückungsebene zu sehen ist. Der Wikipedia-Eintrag »Code Folding« enthält eine Übersicht der Editoren und Entwicklungsumgebungen mit dieser Fähigkeit.
Wenn Sie einen Überblick gewonnen haben, kommen die Detailbetrachtungen. Beginnen Sie beim detaillierten Lesen mit den leicht verständlichen Bereichen, sonst verlieren Sie die Lust und werfen die Quellcodedatei angewidert in die Ecke. Selbst wenn Sie schwer verständliche Codestücke niedergerungen und ihre Funktionen genau begriffen haben, bringt Ihnen das für das Verständnis des Gesamtcodes eher wenig. Investieren Sie die Zeit daher lieber in die oberflächliche Lektüre großer Codemengen.
Wenn Sie merken, dass Sie sich in einem Bereich festgebissen haben und nicht richtig weiterkommen, dann wenden Sie sich lieber einem anderen zu. Sturheit ist eine schöne Tugend und für Softwareentwickler gelegentlich sehr nützlich, aber übertreiben Sie es nicht. Möglicherweise kehren Sie später in einem anderen Geisteszustand oder mit neuen Kenntnissen zu diesem Modul oder dieser Funktion zurück, und dann erschließt sich alles wie von allein.
Debug-Ausgaben, Ausgaben in eine Logdatei und Asserts stehen häufig an wichtigen und/oder fehlergeplagten Bereichen. Anmerkungen wie FIXME und TODO finden sich in Bereichen, wo der Code eher minderwertig ist. Nutzen Sie auch die Informationen in Variablen- und Funktionsnamen - wenn diese Namen zu wenige oder irreführende Auskünfte geben, ist erhöhte Vorsicht geboten.
Lernen Sie rekursive Funktionen erkennen, denn die sind meist ein Indikator dafür, dass hierarchische Daten verarbeitet werden, beispielsweise ein Dateibaum:
function findCsvFiles (fileOrDirectory, csvFiles) {
if (fileOrDirectory.isFile() && (fileOrDirectory.name.endsWith('.csv'))) { return fileOrDirectory;
} else if (fileOrDirectory.isDirectory()) { var files = fileürDirectory.listQ; for (var file : files) {
csvFiles.add(findCsvFiles (files, csvFiles));
Diese Funktion ist rekursiv, weil sie sich im unteren Teil selbst aufruft, falls sie unter den Einträgen in einem Verzeichnis ein Unterverzeichnis gefunden hat. Dann geht sie die Kinder dieses Verzeichnisses durch und hängt die gefundenen CSV-Dateien an das csvFiles-Array an. Falls sie auf ein weiteres Unterverzeichnis stößt, macht sie zunächst dort weiter, bevor sie zum übergeordneten Verzeichnis zurückkehrt.
Lernen Sie erkennen, wie in der Sprache Ihrer Wahl asynchrone Verarbeitung (Threads oder Ajax-Calls) gestartet wird. Das ist ein Zeichen dafür, dass die Verarbeitung zeitlich ganz anders aussehen kann, als der lineare Code nahelegt.
var db_conn;
Thread.new ({
var success = dbconn.connect (database: "mysql@server", user: "johannes", password: "pass"); if (success == false) {
throw DatabaseConnectException.new();
.. //weiterer Code
});
print ("connecting to database");
Dteses Programm verbindet sich in einem parallel laufenden Thread mit der Datenbank, und weil hier eine asynchrone Verarbeitung gestartet wird, wird die pr int-Ausgabe aufberufen, bevor das Programm sich tatsächlich mit der Datenbank verbunden hat. Das hat den Vorteil, dass das User Interface nicht hängt, während das Programm die Datenbank-’-erbindung aufbaut. Aber beim Lesen des Codes muss man darauf achten, dass es in der Zeile mit der print-Anweisung zu früh wäre, »connected to database« zu schreiben, denn ■alls die Datenbankverbindung fehlschlägt, wird die DatabaseConnectException erst nach .' print-Anweisung geworfen werden.
Es ist ungemein befriedigend, ein Stück Code wirklich verstanden zu haben, aber das ist für die Bewältigung einer bestimmten Programmieraufgabe häufig nicht nötig, und für Anfänger auch nicht immer zu erreichen. Wenn Sie Code lesen, um Ihre Programmierfä-skeiten zu verbessern, dann analysieren Sie ruhig auch den für Sie anspruchsvollen bis ins kleinste Detail. Festbeißen ist dann manchmal ganz nützlich, weil es den k i dazu zwingt, den Code Schritt für Schritt nachzuvollziehen - man kommt nicht -:ehr wie sonst mit einer ungefähren Vorstellung davon.
Falls Ihnen das aber viel zu viel ist oder Sie nicht genug Zeit haben, trösten Sie sich: Ein ungefähres Verständnis reicht in der Regel aus, und den Rest lernen Sie dann schon, wenn Sie mit dem Code arbeiten. Ausschließlich diejenigen Codebereiche zu lesen und zu verstehen, die Sie später mit einer gewissen Wahrscheinlichkeit auch benutzen oder umschreiben werden, ist auch deswegen sinnvoll, weil Sie überflüssige Arbeit vermeiden. Auch wenn Code-Studium grundsätzlich sinnvoll und gut ist, gilt das nicht unbedingt für Code, dem Sie später nie mehr begegnen werden.
Wenn Sie eine Sammlung von VBA-Makros5 übernehmen, die in Excel-Dateien eingebettet sind, sollten Sie nicht nur auf den Code schauen. Die Daten in den Excel-Sheets geben Ihnen häufig schneller einen Überblick darüber, wofür der Code gut ist, als die Visual-Basic-Quellen. Ähnliches gilt für Access-Projekte, aberauch für andere Software, die sehr stark auf die Verarbeitung von Daten zugeschnitten ist.
Lernen Sie, bestimmte Datenformate zu erkennen. Beispiele:
• 20060712 ist ein Datestamp, also Jahr, Monat, Tag hintereinander. Dieses Format findet sich häufig bei Datumsangaben in SQL-Datenbanken.
• 1152680400 10-stellige Zahlen, die mit 10 bis 14 anfangen, sind häufig Unix-Timestamps, gerechnet in Sekunden seit 1970.
• 192.168.1.10 Vier durch Punkte getrennte Nummernblöcke, deren Werte zwischen 0 und 255 liegen, deuten auf eine 1Pv4-Adresse hin.
• 2001 :DB8:0:0:211:22FF:FE33:4455 Acht durch Doppelpunkte getrennte Nummernblöcke oder weniger und dafür irgendwo in der Zeichenfolge ein doppelter Doppelpunkt (::) zeigen eine IPv6-Adresse an.
• [09090 Sechs Hexadezimalziffern stehen häufig für Farben.
Wenn Sie ein Problem nicht ganz verstehen und/oder mit den angewendeten Techniken nicht vertraut sind, werden Sie durch das Lesen des Codes nicht unbedingt alles begreifen können, dazu sind Programme zu komplex und häufig auch zu groß. Im Endeffekt hilft häufig nur, das Programm zu starten und seine Funktionsweise zu beobachten.
Wenn Sie den Sourcecode sowieso schon haben, können Sie die Gelegenheit nutzen und Bereiche auskommentieren oder print()-Anweisungen einfügen, um den Programmablauf und die Gliederung des Programms besser zu begreifen. Wenn ein Debugger kein fremdes Wesen für Sie ist (siehe den Abschnitt »Debugger« in Kapitel 13), kommen Sie damit noch schneller ans Ziel.
Eine gute Möglichkeit, um mehr über die Funktion von Code zu erfahren, sind Tests. Wenn Sie Code lesen, der nicht sowieso schon durch Tests dokumentiert ist, dann können Sie selbst Unit-Tests (siehe Kapitel l6) schreiben, um Ihre Vorstellung von der Funktion des Codes mit der Realität abzugleichen.
Wer Kollegen hat, die auch programmieren, oder wer in seiner Freizeit Software entwickelt und Freunde hat, die das auch tun, kann die eigenen Fähigkeiten durch gemeinsames Lesen von Code deutlich verbessern. Wenn Sie sich trauen, dann halten Sie ein Code-Review ab, in dem Sie eigenen Code mit den Freunden oder Kollegen durchgehen. Wenn Ihnen das zu abschreckend erscheint, dann lesen Sie zusammen fremden Code.
Ziel des Code-Lesens ist nicht, herauszufinden, wer das größte Geweih hat und Fehler :cr schlechten Code bei anderen finden kann. Es geht darum, ein Verständnis des Codes zu gewinnen. Gelegentlich wird man beim Lesen die Funktion des Codes nicht ganz verstehen oder sich irren. Wenn man mit mehreren Leuten diskutiert, fällt schnell auf, an welchen Stellen sich die Annahmen über die Funktion des Codes unterscheiden.
Wenn alles andere nicht weiterhilft (aber nicht vorher!), haben Sie die Berechtigung, andere Menschen um eine Erklärung zu bitten. Wie Sie das anstellen, ohne diesen Menschen übermäßig auf die Nerven zu fallen oder ihre Zeit zu stehlen, steht in Kapitel 8.
]
www.codinghorror.com/blog/2012/04/lea rn-to-read-the-source-luke.html.
Douglas Crockford in »Coders at Work<<, S. 107.
Der Java-Entwickler Joshua Bloch in »Coders at Work«, S. 182.
- eii.wikipedia.org/wiki/Nassi-Slmeiderman_diagram.
- en. wikipedia.org/wiki/Flowchart.
VBA steht für Visual Basic for Applications, eine klassische Skriptsprache in Großfirmen.