Coding Convention

Als Programmierstil (engl. code conventions, coding conventions, coding standards) bezeichnet man einen Satz von Regeln, denen sich der Programmierer unterwirft. Üblicherweise werden hierunter Regeln verstanden, nach denen der Quelltext einer Programmiersprache gesetzt wird, wo Leerzeichen stehen sollen, wie einzurücken ist oder wie Bezeichner zu wählen sind. Ob Variablen vor Verwendung deklariert werden, auch wenn dies syntaktisch nicht nötig ist oder ob Compilerdirektiven oder -schalter verwendet werden, sind Elemente des Programmierstils. Der Begriff lässt sich erweitern um die Verwendung von Stereotypen bis hin zu Entwurfsmustern.

Programmierstil dient der Kommunikation im Team und allgemein der schnellen Erfassbarkeit des Quelltexts für Entwickler. Für größere Projekte, deren Erfolg stark von der Qualität der Kommunikation abhängt, werden deshalb häufig Programmierrichtlinien festgelegt.

Zweck

Der Zweck eines definierten Programmierstils ist die Erleichterung der Arbeit aller an einem Programmierprojekt beteiligten Teammitglieder. Das bezieht sich insbesondere auf die Lesbarkeit, Verständlichkeit und Wartbarkeit von Programm-Quelltext bzw. der Eliminierung vermeidbarer Fehlerquellen in Programmen.

Im Sinne der Verständlichkeit und Wartbarkeit kann eine Richtlinie die Verwendung von programmsprachlich erlaubten (aber "unsauberen") Programmkonstrukten einschränken oder ganz verbieten. Die Einhaltung von vorgängig definierten Nomenklaturen für Variablen, Prozeduren und Klassennamen kann Lesbarkeit und Wartbarkeit eines Programmcodes wesentlich verbessern.

Während der Wartung ist die Einhaltung eines definierten Programmierstils noch wichtiger als während der Entwicklung. Als Richtwert gilt, dass 80 % der Lebenszeit eines Softwareprodukts auf die Wartung entfallen. Nur selten wird ein Produkt vom ursprünglichen Programmierer gewartet. Umso wichtiger ist es, dass bereits vom ersten Augenblick an ein guter Programmierstil verwendet wird.

Ein Programmierstil sollte nicht unbedingt wie eine Doktrin ausgelegt werden. Verstöße dagegen sollten erlaubt sein, sofern sie gut begründet sind. Dies kann in Einzelfällen beispielsweise (beim Programmierstil im engeren Sinne) durch optimierte Platzausnutzung den Überblick verbessern, durch Betonung bestimmter Einzelheiten der Verständlichkeit dienen oder als Ad-hoc-Sonderregel für besondere Codeteile die Ziele des Programmierstils mit anderen Mitteln verfolgen.

Quelltextformatierung

Wichtige Aspekte des Programmierstils sind die Anordnung von untergeordneten Programmelementen (Einrückungsstil), die damit unmittelbar auch auf die Positionierung umschließender Syntaxelemente wie {}, [], (), BEGIN oder END Einfluss haben, sowie der Einsatz von Leerzeichen und Leerzeilen und die Verschachtelungstiefe untergeordneter Programmelemente.

Darüber hinaus ist die Abwesenheit von Kommentaren im Quellcode ein Zeichen für einen schlechten Programmierstil. Ein Programmierer muss immer davon ausgehen, dass sein Code auch von anderen gelesen und verstanden werden muss, hierfür sind Kommentare unerlässlich. Heutzutage gibt es auch oftmals feste Formate für Kommentare, die beispielsweise Ein- und Ausgabeparameter einer Funktion oder Methode einzeln erläutern. Dadurch können diese von automatischen Dokumentationsprogrammen wie doxygen oder javadoc verwendet werden, um vollautomatisch eine menschenlesbare Dokumentation zu generieren.

Auch die Namenskonventionen für Symbole spielen eine gewichtige Rolle im Zusammenhang mit der Bewertung des Programmierstils. Der Name eines Symbols sollte die Funktion oder Verwendungsweise hinreichend erklären oder zumindest andeuten. Da heute ausreichend Speicherplatz für den Code zur Verfügung steht, ist die früher übliche platzsparende Verwendung von Kürzeln wie zum Beispiel „dskmngr“ nicht mehr gerechtfertigt. Häufig wird für unterschiedliche Arten von Symbolen auch eine unterschiedliche Schreibweise verwendet, um so am Symbolnamen ablesen zu können, ob es sich um eine Variable, eine Funktion, eine Klasse oder eine Konstante etc. handelt. (Siehe auch Ungarische Notation). In diesem Zusammenhang sind auch die Länge und der Umfang von Symbolen sowie deren Deklarationsreihenfolge von Bedeutung.

Diese Aspekte der Quelltextformatierung beziehen sich in erster Linie auf die optische Lesbarkeit, dadurch jedoch direkt auch auf die Verständlichkeit eines Programmquelltexts.

Style Checker wie beispielsweise CheckStyle können die meisten Kriterien für einen guten Programmierstil bezüglich dieser Elemente überprüfen. Beautifier sind in der Lage, durch Umformatierung des Quelltextes die Einhaltung eines guten Stils bezüglich dieser Elemente zu gewährleisten.

Umstrittene Elemente

Die folgenden Elemente von Programmierstilen sind umstritten. Es folgt zu jedem Element eine Gegenüberstellung der Argumente der jeweiligen Befürworter und Gegner. Falls möglich und als allgemein akzeptiert betrachtbar, schließt sich eine Empfehlung bezüglich des umstrittenen Elements an die Erörterung an.

Zeilenlänge

Oft wird eine Begrenzung der Zeilenlänge als guter Programmierstil angesehen. Für eine solche Begrenzung spricht, dass

• kürzere Zeilen in der Regel leichter lesbar sind als längere (insbesondere leichter als mehrere lange, automatisch nur an Wortgrenzen umgebrochene Zeilen untereinander), siehe den mehrspaltigen Satz von Zeitungen
• sich längere Zeilen meist semantisch in einzelne Teile untergliedern lassen
• Vergleichswerkzeuge wie diff oft zeilenweise arbeiten und dabei Änderungen leichter zu erkennen sind
• bei Beschränkung auf den sicheren druckbaren Bereich (80 Zeichen) semantisch motivierte Zeilenumbrüche und Einrückungen auch im Ausdruck erhalten bleiben

Gegen eine Begrenzung der Zeilenlänge spricht, dass

• dies Handarbeit entweder beim Programmieren oder (besser) bei der Einrichtung der IDE erfordert
• insbesondere neuere APIs lange Symbolnamen verwenden, was die Entstehung sehr langer Zeilen begünstigt
• bei einer Suche mit grep die angezeigte Fundstelle – per Voreinstellung eine einzelne Zeile ohne Kontextzeilen – die vollständige Anweisung enthält

Als Konsens kann gelten, dass lange Zeilen keinesfalls mehr als eine Anweisung enthalten sollen.

Beispiele

Die Zeile

public ModelAndView handleList(HttpServletRequest request, HttpServletResponse response) throws ServletException {
    //...
}

lässt sich nach semantischen Kriterien automatisch wie folgt formatieren (von Eclipse erzeugt):

public ModelAndView handleList(HttpServletRequest request,
                               HttpServletResponse response)
throws ServletException {
    //...
}

Dabei stehen die formalen Parameter der Funktion untereinander, und das wichtige Schlüsselwort „throws“ steht in einer neuen Zeile.

Komplizierter wird es bei folgender Anweisung:

out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new FileOutputStream(new File(baseDir, "test.txt"))), "utf-8"));

Realistischerweise um zwei Ebenen à 4 Leerzeichen eingerückt (Klasse und Methode) und auf einem Drucker mit 80 Zeichen/Zeile ausgedruckt, ergibt sich z. B.:

        out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new
FileOutputStream(new File(baseDir, "test.txt"))), "utf-8"));

Wird nach denselben Kriterien umgebrochen wie im ersten Beispiel, ergibt sich:

out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new FileOutputStream(new File(baseDir,
                                                                                              "test.txt"))),
                                             "utf-8"));

und bei Ausdruck auf demselben Drucker z. B.:

        out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new
FileOutputStream(new File(baseDir,
                                                                               
                      "test.txt"))),
                                                     "utf-8"));

Wenn sich also die maximale Zeilenbreite nicht am druckbaren Bereich orientiert, kann das Umbrechen dieser Zeile die Lesbarkeit im Ausdruck eher erschweren als befördern. Wird die Zeile jedoch wie folgt umgebrochen:

out = new PrintWriter(
          new OutputStreamWriter(
              new BufferedWriter(
                  new FileOutputStream(
                      new File(baseDir,
                               "test.txt"))),
              "utf-8")); // zu OutputStreamWriter

dann bleibt die Lesbarkeit auch im Ausdruck erhalten.

Einrückungsstil

Der Einrückungsstil ist wohl der umstrittenste Punkt eines Programmierstils.

Folgende Empfehlungen gelten jedoch als allgemein anerkannt:

• Festlegung innerhalb eines Projekts, Teil-Projekts, Teams oder Unternehmens. Beispiel: „Für unsere Open-Source-Projekte in C und C++ verwenden wir die GNU-Coding-Standards, für Java grundsätzlich die Code Conventions von SUN und ansonsten die gemäß Allman.“
• Konsequente Umsetzung
• Keine Mischung unterschiedlicher Stile in einem Projekt

Ebenfalls viel diskutiert ist die Frage der Einrückungstiefe für untergeordnete Blöcke und ob man dabei Leerzeichen oder Tabulator den Vorzug geben sollte. So schreibt die Code Convention für Java beispielsweise eine Einrückungstiefe von vier Leerzeichen, die Code Convention für Linux hingegen eine Einrückungstiefe von acht Zeichen vor. Der Vorteil der Einrückung mit Leerzeichen besteht darin, dass die Einrückung unabhängig von den Anzeigeoptionen des Anzeigeprogramms oder Editors stets erhalten bleibt.

Tabulatoren zur Einrückung bieten im Gegenzug den Vorteil, dass jeder Entwickler selbst durch die Konfiguration der Tabulatorschrittweite seines Texteditors die dargestellte Einrückungstiefe bestimmen kann. Einigkeit besteht jedoch bezüglich der Auffassung, dass man beide Varianten nicht mischen sollte. Eine Mischung von Tabulatoren und Leerzeichen bei der Einrückung führt zu uneinheitlichen Einrückungstiefen für Elemente auf der gleichen Hierarchiestufe, was der Lesbarkeit eher abträglich ist.

Regelwerke

Einige Qualitätsnormen im Softwareumfeld (IEC 61508, CMMI, SPICE usw.) fordern explizit die Anwendung bestimmter Regelwerke. Im Automobilindustrieumfeld wird beispielsweise der Standard MISRA-C angewendet.

Programmierstil im weiteren Sinne

Im weiteren Sinne bezieht sich der Programmierstil auch auf:

• Umsetzung eines Programmierparadigmas, wie zum Beispiel der Objektorientierten Programmierung. Verletzung eines von der Programmiersprache zur Verfügung gestellten bzw. unterstützten Paradigmas kann als schlechter Programmierstil bezeichnet werden.
• Anwendung von Entwurfsmustern
• Einsatz passender API-Komponenten
• Typisierung (Wahl des Typs für ein Symbol)
• Vermeidung von Redundanz und Entfernung überflüssiger Programmteile
• Unabhängigkeit verschiedener Programmteile (Modularität)
• Abstraktionsgrad und Verallgemeinerung
• Wiederverwendbarkeit
• Robustheit durch Fehler- und Ausnahmebehandlung

Diese Elemente beziehen sich im Wesentlichen auf die inhaltliche Verständlichkeit eines Programms.

Die Beurteilung eines Programmierstils bezüglich dieser Elemente erfordert in der Regel ein tiefes semantisches Verständnis des Programmquelltextes. Aus diesem Grund sind Style Checker und Beautifier bisher nicht oder nur äußerst eingeschränkt in der Lage, die Überprüfung auf einen guten Programmierstil bezüglich dieser Elemente durchzuführen bzw. eine Einhaltung gewährleisten zu können.

Siehe auch

• Extreme Programming

Weblinks

• Code Conventions for the Java Programming Language (Englisch)
• A Programming Style for Java (Englisch) - Aufsatz von Paul Haahr, reich an Gründen und Hintergründen
• The GNU Coding Standards (Englisch)
• Linux Kernel Coding Style (Englisch)
• ActionScript Coding Standards von MacroMedia (PDF, Englisch)
• Object Pascal Style Guide (Englisch)