Unsinnige Code-Änderungen

Letzte Änderung am 8. November 2015 by Christoph Jüngling

Wer unter VB6 oder VBA mit Quellcodeverwaltung arbeitet, hat sicher schon festgestellt, dass der Editor oft vollkommen unsinnige Änderungen am Code vornimmt. Dies sind alles keine essentiellen Änderungen, sondern eher Kleinigkeiten am Rande, für die oft keine Ursache zu erkennen ist. Ich rede von Änderungen in der Groß-/Kleinschreibung.

Die Programmiersprache VB(A) kennt streng genommen keinen Unterschied zwischen großen und kleinen Buchstaben. Dies betrifft natürlich nur Programmbefehle und Variablen etc. Innerhalb von Anführungszeichen wird dies sehr wohl unterschieden. Allerdings hat man als Entwickler den Eindruck, dass die Schreibweise für Visual Basic durchaus wichtig ist. Schreiben Sie zum Beispiel eine For-Next-Schleife mit kleinen Buchstaben und verlassen Sie die Zeile, “korrigiert” der Editor dies in die übliche Schreibweise, bei der der Anfangsbuchstabe eines jeden Wortes groß geschrieben wird.

For i = 0 To 100 Step 20

Auch die Namen von Variablen, Konstanten, Subs und Funktionen werden in der Schreibweise automatisch gleich gehalten, und zwar stets auf der Grundlage ihrer Deklaration. Bei den Types und Enums scheint das — wenn ich mich recht erinnere — leider nicht mehr zu funktionieren, zumindest nicht in VB6.

Was generell wie ein Vorteil klingt, verschwindet spätestens dann, wenn mal wieder ein Variablenname seine Schreibweise ändert. Manchmal nämlich wird die Schreibweise leider an den Ort des letzten Zugriffs angepasst. UPDATE: Stellenweise scheint der Editor auch Methoden einer Klasse in der Schreibweise zu verändern, nur weil eine zufällig gleich heißende Funktion (oder eine Methode/Attribut einer anderen Klasse) anders geschrieben wurde.

Dann entstehen beim nächsten Commit zahlreiche Änderungen, die man zunächst aus diesem herausnehmen muss. Oder man akzeptiert sie nolens volens und ärgert sich dann später, wenn der Code analysiert werden oder ein Bug gefunden werden soll. Mir ist es schon häufiger passiert, dass ich fast 100 Änderungen in einem Commit hatte, obwohl ich gerade mal eine Zeile wirklich bearbeitet hatte.

Jetzt reicht’s!

Python-logoUnd dann irgendwann dachte ich mir: Jetzt reicht’s! Ich schrieb mir ein kleines Python-Programm, das ich vor dem Commit aufrufe und das — projektspezifisch definiert — sämtliche “Korrekturen” von VB(A) wieder rückgängig macht. Jedes mal, wenn ich wieder eine Änderung entdecke, ergänze ich die Liste der Korrekturbegriffe. Eines Tages, wenn meine Definition vollständig ist, brauche ich dann nur noch einen Doppelklick auf mein Tool zu machen, bevor ich den neuen Code committe. Diese Definitionsliste ist immer projektspezifisch in einer INI-Datei, sie kann und muss also für jedes Projekt individuell angepasst werden.

Wenn ich dann sicher bin, dass alles funktioniert, kann ich den Aufruf dieses Hilfsprogramms auch in den Pre-Commit-Hook von Mercurial integrieren. Wie das geht, erkläre ich demnächst hier.

Fazit

Die Entwicklung dieses Tools hat im Vergleich recht wenig Zeit gekostet, mir dagegen jedoch viel Zeit und Ärger erspart. Dieses kleine Tool habe ich nach einem Gespräch mit einem Kollegen auf der AEK18 in meinem Account bei Bitbucket veröffentlicht: https://bitbucket.org/juengling/autocorrection

Wer an Python interessiert ist, kann sich dort auch den Quellcode herunterladen, nötig ist das aber nicht. Es gibt im dortigen Downloadbereich nämlich auch ein Setup für Windows. Wer das Programm darüber installiert, braucht keinen Python-Interpreter auf seinem Rechner (der für die Ausführung aus dem Quellcode natürlich erforderlich wäre).  Im Wiki wiederum findet sich eine Anleitung für die Benutzung. Und zuguterletzt kann, falls jemand einen Fehler findet oder eine neue Idee hat, er dies gerne im Bugtracker eintragen.

Das Tool wird kostenlos zur Verfügung gestellt, eine Garantie für die Funktion im Sinne des Benutzers kann ich natürlich nicht geben.

Fröhliches Programmieren!

Ähnliche Artikel:

2 Kommentare

  1. Das Problem ist wirklich ziemlich unangenehm, für viele Entwickler. – Wie ich durch zahlreiche Ivercy-Supportanfragen zu dem Thema immer wieder mitbekomme.
    Dein Lösungsansatz ist eine interessante Idee. Ich werde ihn mal im Hinterkopf behalten. Vielleicht lässt sich in Ivercy ein ähnliches Feature integrieren, um die häufigen, falsch-positiven Änderungskennzeichnungen zu reduzieren.

    • Rainer Bauer auf 2. November 2015 bei 15:00
    • Antworten

    Danke,
    ein sehr nützliches Werkzeug!
    Rainer Bauer

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

19 − sieben =