Regeln in der Programmierung sind nicht in Stein gemeißelt und in kleinen Teams oft auch nicht notwendig. Aber in Bezug auf die Projektziele Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit oder Robustheit ist der eine oder andere Ratschlag sehr gewinnbringend und nützlich.

Coding Richtlinien

Vor allem im Team macht es Sinn sich auf einen Leitfaden bei der Codierung festzulegen. Ludewig et al. erwähnt folgende Richtlinien:

• definiere wie die Bezeichner (Klassen-, Variablennamen, etc.) zu wählen sind
• lege das Layout bei der Codierung fest (Klammenr, Tabulatoren, Einrückungen, etc.)
• wie die Schnittstellen zu definieren sind (z.B. Ordnung der Parameter)
• wie Standardkommentare zu verwenden sind

Darüber hinaus verweist Ludewig et al. auf offizielle Regelwerke für bestimmte Programmiersprachen, wie den „GNU Coding Standard“ für die Sprache C oder den „JAVA Coding Style Guide“. Darin werden beispielsweise die Beschränkung der Hauptprogramme, der Prozeduren oder der Pakete auf eine bestimmte Anzahl von ausführbaren Zeilen Programmcode (ELOC – executable lines of code) festgelegt. Oder auch wieviele Attribute oder Methoden eine Klasse beinhalten darf.

Unabhängige Ratschläge

Eine gute Beschreibung liefert Ludewig et al. zu den programmiersprachenunabhängigen Ratschlägen von Fairley(1985) wobei einige davon immer noch gute Hinweise liefern.

Don’t be too clever

Während der Codierung kann es manchmal passieren, dass man ein komplexes Problem mit einer ebenso komplexen Programmierung löst, das Problem dabei ist das man die Lösung später nicht mehr nachvollziehen kann und sie daher auch nicht mehr versteht, selbst derjenige der sie entworfen hat.

Don’t nest too deeply

Besagt das sehr stark verschachtelte Kontrollstrukturen vermieden werden sollten.

Don’t suboptimize

Vor allem bei Spielen müssen meist zum Ende hin einige Komponenten optimiert werden um die Performance zu verbessern, dabei sollte abgewogen werden ob die Anwendung durch die Optimierung tatsächlich, messbar besser wird. Wenn nicht, besagt diese Regel wird das Programm kaum besser jedoch mit Sicherheit schlechter lesbar und wartbar.

Routines having more than five parameters?

Wenn Methoden zu viele Parameter aufweisen, ist das meist ein Anzeichen dafür das beim Entwurf was schief gelaufen ist und sie möglicherweise mehr macht als sie soll (Prinzip der Verantwortlichkeit).

Don’t use an identifier for multiple purposes

Die Wahl der Bezeichner wurde schon erwähnt, mit dieser Regel wird sie um einen Ratschlag ergänzt. Es verschlechtert die Lesbarkeit des Codes wenn ein Bezeichner für unterschiedliche Zwecke verwendet wird.

Es gibt mittlerweile eine menge Literatur die diese Regeln auf die Spitze treiben, dabei sei jedem Programmierer selbst überlassen was in der Praxis funktioniert.

Literaturtip

Links

Code Conventions for the Java ^TM Programming Language
GNU coding standards
C++ Coding Standard
Google Java Style Guide