Programmierstil

Grundidee und Bedeutung

Ein Programmierstil ist das Erstellen von Quellcode nach bestimmten vorgegebenen Regeln. Dazu gehören englische Bezeichnungen wie code conventions, coding conventions oder coding standards. Programmierstil ist ein Teilaspekt der Softwarequalität. Er soll vor allem Verständlichkeit und Wartbarkeit von Software unterstützen; diese gelten nach ISO/IEC 9126, aktualisiert durch ISO/IEC 25000, als Kriterien für Softwarequalität.

Ein Programmierstil regelt nicht, was ein Programm leisten soll, sondern wie sein Quellcode formal und strukturell gestaltet wird. Dabei wirken drei Aspekte zusammen: die Vorschrift, also die Definition von Regeln, Konventionen oder Standards; die Handlung, also das Umsetzen dieser Regeln beim Programmieren; und das Ergebnis, also der Quelltext mit seiner Struktur und seinem Erscheinungsbild. Dieses Ergebnis kann in der Qualitätssicherung daraufhin überprüft werden, ob die Regeln eingehalten wurden.

In einem weiteren Sinn können auch Programmierparadigmen, also grundlegende Arten des Programmierens, als fundamentaler Programmierstil gelten. Die Beurteilung eines Programmierstils erfordert aber meist ein tiefes semantisches Verständnis des Quelltexts. Deshalb können Style Checker und Beautifier nur eingeschränkt prüfen oder sicherstellen, ob ein guter Programmierstil in allen Elementen eingehalten wird.

Ziele im Projekt

Ein definierter Programmierstil soll die Arbeit aller Teammitglieder in einem Programmierprojekt erleichtern. Besonders wichtig sind Lesbarkeit, Verständlichkeit und Wartbarkeit des Quelltexts. Außerdem sollen vermeidbare Fehlerquellen in Programmen beseitigt werden.

Eine Richtlinie kann auch erlaubte, aber als unsauber betrachtete Programmkonstrukte einschränken oder verbieten. Dazu gehört etwa, dass für Variablen, Prozeduren und Klassennamen vorher festgelegte Nomenklaturen verwendet werden. Solche Namensregeln können die Lesbarkeit und Wartbarkeit eines Programmcodes deutlich verbessern.

Während der Wartung ist ein definierter Programmierstil besonders wichtig. Als Richtwert gilt, dass 80 % der Lebenszeit eines Softwareprodukts auf die Wartung entfallen. Oft wird ein Programm nicht von der Person gewartet, die es ursprünglich geschrieben hat. Deshalb soll ein guter Programmierstil von Anfang an verwendet werden.

Ein Programmierstil soll aber nicht zwingend wie eine Doktrin behandelt werden. Verstöße können erlaubt sein, wenn sie gut begründet sind. In Einzelfällen kann eine abweichende Lösung zum Beispiel durch bessere Platzausnutzung den Überblick verbessern, bestimmte Einzelheiten verständlicher machen oder als besondere Regel für spezielle Codeteile die Ziele des Programmierstils auf andere Weise erreichen.

Typische Bestandteile

Welche Inhalte zu einem Programmierstil gehören, kann je nach Situation unterschiedlich sein. Die Bandbreite reicht von einfachen Vorgaben zur Code-Strukturierung, etwa Einrückungen, bis zu Festlegungen für fast alle Details, die das Wie der Implementierung betreffen.

In größeren Projekten und Unternehmen werden Anforderungen an den Programmierstil häufig in Programmierrichtlinien festgelegt. Diese bauen oft auf überbetrieblichen oder internationalen Konventionen und Empfehlungen auf, zum Beispiel der Ungarischen Notation oder den Java-Code-Conventions. Manche Regeln hängen stark von der verwendeten Programmiersprache ab. Auch die Bedeutung einzelner Regeln kann verschieden sein, etwa von Muss bis nicht relevant, abhängig davon, ob Software nur einmalig oder dauerhaft genutzt werden soll. Im privaten oder nicht-kommerziellen Bereich nutzen Entwickler häufig einen gelernten oder intuitiven Stil, der nicht ausdrücklich festgelegt ist.

Beispiele für Elemente eines Programmierstils sind: übliche Vorgehensweisen im gewählten Programmierparadigma, etwa objektorientierte Programmierung; Namenskonventionen für Bezeichner; Entwurfsmuster; Compilerdirektiven und -Schalter; Strukturierung des Codes durch Einrückungen, Modul- oder Prozedurgröße und ein mögliches GOTO-Verbot; Regeln zu Leerzeichen, Einrückung und maximaler Zeilenanzahl einer Routine; Typisierung; Initialisieren von Variablen; Zugriff auf Variablen fremder Objekte oder Prozeduren; Gestaltung von Funktionsaufrufen mit Parameterübergaben und Rückgabewerten; vorgeschriebene Standardkomponenten wie Unterprogramme oder APIs; Vermeidung von Redundanz und Wiederverwendbarkeit durch Modularisierung; Unabhängigkeit verschiedener Programmteile; Einheitlichkeit bei ähnlichen Problemen, zum Beispiel durch normierte Programmierung; Robustheit durch Fehler- und Ausnahmebehandlung; sowie Umfang und Form der Dokumentation.

Quelltextformatierung

Zur Quelltextformatierung gehören wichtige sichtbare Aspekte des Programmierstils. Dazu zählen die Anordnung untergeordneter Programmelemente, der Einrückungsstil, die Positionierung umschließender Syntaxelemente wie {}, [], (), BEGIN oder END, der Einsatz von Leerzeichen und Leerzeilen sowie die Verschachtelungstiefe untergeordneter Programmelemente.

Auch Namenskonventionen für Symbole sind wichtig. Ein Symbolname sollte die Funktion oder Verwendungsweise ausreichend erklären oder zumindest andeuten. Da heute genügend Speicherplatz für Code vorhanden ist, gilt die früher platzsparende Verwendung von Kürzeln wie „dskmngr“ nicht mehr als gerechtfertigt. Häufig werden verschiedene Arten von Symbolen unterschiedlich geschrieben, damit man am Namen erkennen kann, ob es sich zum Beispiel um eine Variable, Funktion, Klasse oder Konstante handelt. In diesem Zusammenhang werden auch Länge, Umfang und Deklarationsreihenfolge von Symbolen als bedeutsam genannt.

Diese Formatierungsaspekte beziehen sich zuerst auf die optische Lesbarkeit. Dadurch beeinflussen sie aber auch direkt die Verständlichkeit eines Programmquelltexts. Style Checker wie Checkstyle können viele Kriterien in diesem Bereich überprüfen. Beautifier können Quelltext umformatieren und dadurch die Einhaltung bestimmter Formatierungsregeln sicherstellen.

Umstrittene Regeln

Einige Elemente des Programmierstils sind umstritten. Dazu gehören Kommentare, Zeilenlänge und Einrückungsstil. Bei Kommentaren gilt: Sie sollen nichttriviale oder nichtoffensichtliche Sachverhalte beschreiben, aber keine Informationen wiederholen, die schon klar aus dem Programmcode erkennbar sind. Die Menge an Kommentaren soll sich auf Informationen beschränken, die für das Verständnis des Programms wichtig sind. Das kann auch von der Programmiersprache abhängen, etwa davon, ob sprechende Namen gut verwendbar sind.

Zu viele Kommentare können auf schlechte Codequalität hinweisen. Wenn ein Kommentar nötig erscheint, sollte eine alternative Implementierung geprüft werden. Zu wenige Kommentare können bei der Wartung zu höherem Einarbeitungsaufwand oder im schlimmsten Fall zu Fehlimplementierungen führen. Früher galt fehlende Kommentierung allgemein als schlechter Stil. Seit Refactoring und Clean Code wird dies differenzierter gesehen. Robert Cecil Martin betont, dass Kommentare schlechten Code niemals ausgleichen und Code möglichst selbsterklärend sein sollte; er unterscheidet zwischen guten und schlechten Kommentaren.

Bei der Zeilenlänge wird oft eine Begrenzung als guter Stil angesehen. Dafür spricht, dass kürzere Zeilen meist leichter lesbar sind, lange Anweisungen oft sinnvoll in Teile gegliedert werden können, Vergleichswerkzeuge wie diff Änderungen zeilenweise leichter sichtbar machen und bei 80 Zeichen semantisch gesetzte Umbrüche und Einrückungen auch im Ausdruck erhalten bleiben. Gegen eine Begrenzung spricht, dass sie Handarbeit oder IDE-Einstellungen erfordert, lange Symbolnamen in neueren APIs sehr lange Zeilen begünstigen und Suchwerkzeuge wie grep bei ungekürzten Zeilen die vollständige Anweisung zeigen können. Als Konsens gilt, dass auch lange Zeilen keinesfalls mehr als eine Anweisung enthalten sollen.

Der Einrückungsstil gilt als besonders umstritten. Allgemein anerkannt sind aber feste Regeln innerhalb eines Projekts, Teilprojekts, Teams oder Unternehmens, konsequente Umsetzung und keine Mischung verschiedener Stile in einem Projekt. Diskutiert wird auch die Einrückungstiefe und die Wahl zwischen Leerzeichen und Tabulatorzeichen. Die Java-Code-Convention schreibt vier Leerzeichen vor, die Linux-Code-Convention acht Zeichen. Leerzeichen erhalten die Einrückung unabhängig vom Anzeigeprogramm oder Editor. Tabulatoren erlauben jedem Entwickler, die angezeigte Einrückungstiefe selbst einzustellen. Einigkeit besteht darin, Leerzeichen und Tabulatoren nicht zu mischen, weil sonst Elemente auf gleicher Hierarchiestufe unterschiedlich eingerückt erscheinen können.

Regelwerke und Kontrolle

Einige Qualitätsnormen im Softwareumfeld verlangen ausdrücklich die Anwendung bestimmter Regelwerke für die Programmierung. Genannt werden IEC 61508, CMMI und SPICE. In der Automobilindustrie ist häufig der Programmierstandard MISRA-C vorgeschrieben.

Solche Regelwerke machen Programmierstil überprüfbarer und verbindlicher. Sie passen zu der Grundidee, dass Programmierstil nicht nur persönliche Gewohnheit ist, sondern als Anforderung an Softwarequalität verstanden werden kann.