Quelltextformatierung

Als Quelltextformatierung bezeichnet man die Formatierung eines Quelltexts nach bestimmten Regeln. Zweck ist das Verbessern der Programmcode-Lesbarkeit, die eigentliche Funktionalität der Programme ist davon nicht betroffen.

Quelltextformatierung ist als Funktion in manchen integrierten Entwicklungsumgebungen enthalten und wird dabei bei der Erzeugung von Quelltext angewendet. Es gibt aber auch eigenständige Programme, so genannte Quelltext-Formatierer (engl. source formatter oder auch beautifier), die es dem Programmierer ermöglichen, bereits vorhandenen Quelltext in ein gut bzw. besser lesbares Format zu bringen.

Die Verwendung einer Quelltextformatierung ist besonders dann nützlich, wenn sich der Programmierer an einen vorgegebenen Programmierstil halten muss, der ihm vorschreibt, wie er seinen Quelltext zu gestalten hat.

Insbesondere bei Programmiersprachen, die eine C-ähnliche Syntax haben, z. B. C++, Java, C#, ist die Quelltextformatierung weit verbreitet.

In den Programmiersprachen F#, Elm, Python, Occam und einigen anderen ist Quelltextformatierung ein Syntaxelement. Blöcke werden hier durch ihre Einrückung festgelegt, wodurch Leerzeichen eine syntaktische Bedeutung bekommen.

Beispiele für Quelltext-Formatierer sind die freien Programme indent und astyle. Auch Editoren wie Emacs oder Vim verfügen intern über entsprechende Formatierungshilfen, ebenso wie Visual Studio.

Vorteile der Quelltextformatierung

• Einhaltung eines Programmierstils (engl. code convention)
• Vereinheitlichung des Quelltextlayouts
• Erhöhung der Lesbarkeit
• Erhöhung der Wartbarkeit

Die Quelltextformatierung hat zum Ziel, den Programmierern die Arbeit mit Quelltexten zu erleichtern, insbesondere bei der Übernahme von Quelltexten anderer Programmierer oder der Arbeit in Teams. Einige quasigenormte Varianten finden sich im Artikel Einrückungsstil.

Änderungen bei der Quelltextformatierung

• Vereinheitlichung der Einrückung, Einhaltung eines bestimmten Einrückungsstils
• Entfernen oder Hinzufügen von Blöcken bei modifizierenden Anweisungen wie if, else, for, while, do usw.
• Vereinheitlichung von Leerzeichen vor der Argumentliste, z. B.
  • Leerzeichen vor den Argumenten modifizierender Anweisungen,
  • keine Leerzeichen vor den Argumentlisten von Funktionsaufrufen oder
  • keine Leerzeichen vor der Parameterliste einer Funktionsdeklaration.
• konsequent einheitliche Positionierung der {} für Blöcke
• Einfügen von () gemäß der Operatorpriorität bei Operatoren mit allgemein unklarer Priorisierung

Weiter fortgeschrittene Algorithmen für Quelltextformatierung beherrschen außerdem:

• Vereinheitlichung von Symbolnamen
• Umbenennung von Symbolen gemäß Konventionen, z. B. m_MainControl in mainControl
• Ergänzung von Rümpfen für Dokumentationskommentare
• Übernahme von Aufgaben von Code-Analysewerkzeuge, bis hin zum Vorschlag von Refaktorierungen

Beispiele für die Arbeitsweise

Ausgangsquelltext:

   for (int i=0;i<10;i++)
    if( values[i]>0&&values[ i+1 ]>0 )
    {
            out.println ("found!");
 break;
    }

Ergebnis der Formatierung:

for (int i = 0; i < 10; i++) {
    if (values[i] > 0 && values[i + 1] > 0) {
        out.println("found!");
        break;
    }
}

Änderungen:

• Grundsätzlich Blöcke hinter for, if u. ä. auch wenn Einzelanweisungen erlaubt sind (erlaubt leichtes Ergänzen von Anweisungen im Block)
• Die Einrückung wurde konsequent vereinheitlicht (auf je 4 Leerzeichen)
• öffnende geschweifte Klammer auf gleicher Zeile (ein häufiger Stil in Java und C++)
• auflockernde Leerzeichen wurden streng nach Regeln gesetzt:
  • hinter Schlüsselwörtern wie if, while…
  • kein Leerzeichen hinter öffnender und vor schließender runder Klammer (analog eckige Klammern)
  • Raum zwischen binären Operatoren (solche mit zwei Operanden)

Auch wenn der hier dargestellte Stil – z. B. in der Java-Programmierung – relativ verbreitet ist, gibt es eine Vielzahl von anderen Stilen, die teils durch die Tradition, teils durch die Eigenschaften der jeweiligen Programmiersprache begründet sind.

Nachteile des Einsatzes

Programme, die die Quelltextformatierung durchführen, sind nicht in der Lage, wie Menschen die Bedeutung eines Quelltextes zu erfassen. Die Regeln für die Umformatierung sind sehr schematisch und ausdruckslos. Bewusst vorgenommene, dem Zweck der Verständlichkeit dienende Verstöße gegen die den Umformatierungsregeln zu Grunde liegenden Konventionen gehen verloren. Beispiel:

int width = minwidth*2 + padding*4;

wird unter Umständen zu

int width = minwidth * 2 + padding * 4;

Der Konventionsverstoß des Programmierers diente offensichtlich dem Zweck, die Verständlichkeit des Programms zu erhöhen, indem er durch das Weglassen von Leerzeichen die höhere Priorität der Multiplikation (*) im Vergleich zur Addition (+) zum Ausdruck brachte. Diese nicht für das Programm aber für einen lesenden Programmierer relevante Information ging durch die Quelltextformatierung verloren. Ist die Operatorrangfolge nicht eindeutig erkennbar, sollten stattdessen Klammern gesetzt werden, durch diese können auch Fehler durch falsch angenommene Rangfolgen vermieden werden.

Als weiterer Nachteil wird häufig angeführt, dass Quelltextformatierung den „persönlichen Stil“ eines Programmierers zerstöre. Dem kann meist entgegengesetzt werden, dass es beim Programmieren im Team nicht auf den persönlichen Stil und das Ego Einzelner ankommt, sondern darauf, dass dem Team als ganzes ein angenehmes und zügiges Arbeiten ermöglicht werden sollte. Das bedeutet, dass auf persönlichen Stil zu verzichten und eine für das gesamte Team gültige Regelung zu befolgen ist.