Gute Zeichen – Schlechte Zeichen

Letzte Änderung am 24. Februar 2022 by Christoph Jüngling

Groß-/Kleinschreibung ist für VBA eigentlich egal, ständige Änderungen derselben jedoch in der Quellcodeverwaltung eher störend. In diesem Artikel geht es um die Idee hinter Casey, meinem Tool für politisch korrekte Formatierung.

Das Grundproblem: Der integrierte Editor von Visual Studio 98 und VBA geht sehr nachlässig mit Groß-/Kleinschreibung um. Beides nutze ich häufig.

VBA steckt bekanntermaßen in den Komponenten von Microsoft Office drin, wobei ich hier besonders Access verwende. Mittels OASIS exportiere ich den Code regelmäßig, um ihn in die Quellcodeverwaltung zu bekommen. Eine Access-MDB oder -ACCDB würde hier nur einen fetten Brocken Binärdaten ablegen – ausreichend für die Archivierung, aber schlecht für alles andere, was man mit Quellcodeverwaltung sinnvolles anstellen kann.

Visual Studio 98 benutze ich, um ein altes VB6-Projekt noch ein wenig zu pflegen, bis der Nachfolger bereit ist; man könnte es Palliativprogrammierung nennen.

Quellcodeverwaltung

Quellcodeverwaltungssysteme gibt es zahlreich. Sie sollen die Entwicklungsgeschichte des Programmcodes nachvollziehbar machen. Im Zusammenspiel mit einem Bugtracker oder sogar einem ALM-Tool lässt sich dann auch herausfinden, welche Änderungen für welchen Bug oder Feature Request durchgeführt wurden.

Dabei geht es weniger um die Suche nach dem Schuldigen (Entwickler), obwohl Befehle wie “praise” und “blame” (SVN) oder Meldungen wie “culprit found” (Hg) dies vermuten lassen. In erster Linie stellt sich bei der Untersuchung eines Bugs die Frage, wann genau dieser hinein gekommen ist, also konkret in welchem Commit. Denn dann kann ich ermitteln, in welchen Branches sich der Fehler fortgepflanzt hat und in welchen Releases er enthalten ist. Daraus würden sich unter Umständen weitere Aktionen ableiten lassen, z.B. ein Bugfix-Release für eine ältere, aber noch unterstützte Version herauszugeben.

Bei einer derartigen Analyse will ich mich möglichst auf das Problem konzentrieren. Hunderte von Änderungen in einem Commit verwirren sehr stark und lassen unter Umständen die eigentlich interessante Stelle in der Masse an Änderungen untergehen. Das ist ebenso eine Motivation dafür, kleinschrittig zu committen, wie dafür, sinnlose Änderungen aus der Quellcodeverwaltung herauszuhalten. Die Kleinschrittigkeit ist eine reine Frage der Disziplin des Entwicklers, deren Fehlen sich nicht mit technischen Ansätzen ausgleichen lässt. Aber bei den sinnlosen Änderungen durch Groß- und Kleinschreibung kann ein Tool wie Casey helfen.

Aus Alt mach Neu

Im November 2015 hatte ich bereits einen Blogartikel geschrieben, in dem ich das Programm “Autocorrection” vorgestellt habe. Es liegt im wahrsten Sinne des Wortes im Bitbucket :-) Das Programm tat gute Dienste, hatte aber noch einen entscheidenden Nachteil: Ich musste für jedes Projekt die Namensliste selbst verfassen, damit alle Bezeichner in der richtigen Schreibweise korrigiert werden konnten. Der zweite Nachteil war, dass auch solche Worte, die neben der Deklaration auch in einem String oder Kommentar vorkamen, ebenfalls “korrigiert” wurden. Das war vielleicht nicht so schlimm, aber formal gesehen ein Fehler.

Daher habe ich bereits im März 2016 mit einer Neuentwicklung unter dem Namen “Casey” begonnen. Die Grundidee dabei war, dass die Namen der Bezeichner vom Programm selbst ermittelt werden sollten, denn die entsprechenden Deklarationen sind mit Regular Expressions leicht aus dem Code zu ermitteln. Um das nicht zu unübersichtlich zu machen, habe ich jeden Ausdruck in einen eigenen Regex verpackt. Diese werden dann der Reihe nach abgearbeitet und sind durch das Konzept auch leicht erweiterbar (falls man etwas vergessen hat) oder sogar auf andere Programmiersprachen anpassbar. Spätestens in Version 1.0 werden diese dann aus einer Datei gelesen werden.

[
    r'^Private WithEvents (\w+)',
    r'^Public WithEvents (\w+)',
    r'^Const (\w+)',
    r'^Private Const (\w+)',
    r'^Public Const (\w+)',
    r'^Private Type (\w+)',
    r'^Public Type (\w+)',
    r'^Private Enum (\w+)',
    r'^Public Enum (\w+)',
    r'^Private Sub (\w+)\(',
    r'^Public Sub (\w+)\(',
    r'^Private Function (\w+)\(',
    r'^Public Function (\w+)\(',
    r'^Private Property (\w+)\(',
    r'^Public Property (\w+)\(',
    r'^Dim (\w+) As',
    r'^Private (\w+) As',
    r'^Public (\w+) As',
]

Der zweite wichtige Punkt war, dass Literal-Strings und Kommentare diesmal nicht verändert werden sollten. Um diese zu erkennen, sind das Gänsefüßchen (Anführungsstrich) und das Apostroph im Moment noch fest im Code verankert (Funktion “split_line_into_parts”). Ich werde mal schauen, ob ich diesen Mechanismus noch flexibler gestalten kann.

Auch die Dateinamens-Muster sind anpassbar gestaltet (Funktion “get_file_patterns”). Sie sind im Moment für VBA und OASIS voreingestellt, werden aber später ebenfalls aus einer Datei gelesen.

Der Aufruf ist auch recht einfach:

casey VERZEICHNIS

Dabei werden alle Dateien gemäß Pattern durchgegangen, die Deklarationen ausgelesen und dann an allen Stellen gepatcht, wo dies nötig ist.

Tja, und das war’s vorerst. Ich wünsche viel Spaß beim Testen, empfehle jedoch, vorab jeweils eine Sicherung zu machen. Eine Idee wäre, die von OASIS exportierten Dateien zunächst in Git zu committen, dann das Tool drüberlaufen zu lassen und anschließend mit einem --amend den (lokalen!) Commit nach Prüfung zu wiederholen. Bei Zufriedenheit kann dann ein Push erfolgen.

Wenn der Test über einen gewissen Zeitraum erfolgreich verläuft, wäre die Integration in einen “Precommit-Hook” sicher eine gute Idee. Falls Fehler auftreten, hätte ich gern einen Hinweis darauf im Issue-Tracker. Dort sind auch bereits Erweiterungsideen eingetragen, dabei muss es aber nicht bleiben.


Um das Wortspiel zu verstehen, muss man wissen, dass ich den Code damals noch bei dem Anbieter “Bitbucket” (Atlassian) gehostet hatte. Das ist nun Vergangenheit, daher habe ich den Link entfernt.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

zwei × vier =