Quelltext der Seite Quelltextformatierung

Als '''Quelltextformatierung''' bezeichnet man die Formatierung eines [[Quelltext]]s 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 [[Integrierte Entwicklungsumgebung|integrierten Entwicklungsumgebungen]] enthalten und wird dabei bei der Erzeugung von Quelltext angewendet. Es gibt aber auch eigenständige [[Computerprogramm|Programme]], so genannte ''Quelltext-Formatierer'' (engl. {{lang|en|''source formatter''}} oder auch {{lang|en|''beautifier''}}), die es dem [[Softwareentwickler|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 (Programmiersprache)|C]]-ähnliche [[Syntax]] haben, z.&nbsp;B. [[C++]], [[Java (Programmiersprache)|Java]], [[C-Sharp|C#]], ist die Quelltextformatierung weit verbreitet.

In den Programmiersprachen [[F-Sharp|F#]], [[Elm (Programmiersprache)|Elm]], [[Python (Programmiersprache)|Python]], [[Occam]] und einigen anderen ist Quelltextformatierung ein Syntaxelement. Blöcke werden hier durch ihre Einrückung festgelegt, wodurch [[Leerraum|Leerzeichen]] eine syntaktische Bedeutung bekommen.

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

== Vorteile der Quelltextformatierung ==
* Einhaltung eines [[Programmierstil]]s (engl. {{lang|en|''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 <code>if</code>, <code>else</code>, <code>for</code>, <code>while</code>, <code>do</code> usw.
* Vereinheitlichung von Leerzeichen vor der Argumentliste, z.&nbsp;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.&nbsp;B. m_MainControl in mainControl
* Ergänzung von Rümpfen für Dokumentationskommentare
* Übernahme von Aufgaben von Code-Analysewerkzeuge, bis hin zum Vorschlag von [[Refactoring|Refaktorierungen]]

== Beispiele für die Arbeitsweise ==
Ausgangsquelltext:

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

Ergebnis der Formatierung:

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

Änderungen:
* Grundsätzlich Blöcke hinter for, if u.&nbsp;ä. 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.&nbsp;B. in der Java-Programmierung<ref>[http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html ''Code Conventions for the Java Programming Language.''] In: ''oracle.com'', [[Sun Microsystems]], 20. April 1999. (englisch)</ref> – 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:
<pre>
int width = minwidth*2 + padding*4;
</pre>
wird unter Umständen zu
<pre>
int width = minwidth * 2 + padding * 4;
</pre>
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.

== Einzelnachweise ==
<references />

[[Kategorie:Programmierung]]