Welche Punkte und Regeln sollen beim Schreiben von Programmcode beachtet und eingehalten werden? Durch welche Mittel und Wege ist es möglich, die Codequalität trotz oder gerade wegen größer werdender Teams und steigender Komplexität der Projekte zu steigern?
Ein guter Ansatz ist das Aufstellen von Programmierrichtlinien in denen Vorgaben für den Code und die Kommentierung des Codes gemacht werden. Werden die Richtlinien eingehalten, so erhält man Code „aus einem Guss“. Bildlich gesprochen einigt man sich auf eine „einheitliche Sprache“, nach deren Konventionen der Code erstellt wird. Code geht während der Entwicklung durch viele Hände, daher sollten die Richtlinien streng und umfangreich ausgelegt und verfasst werden, um den Zeitverlust durch schlecht verständlichen Code zu verhindern. Zudem wird durch die Richtlinien und deren Einhaltung ein gewisser Qualitätsstandard innerhalb der Firma geschaffen, sodass keine unkommentierten oder mit Sprunganweisungen (goto) übersäten Programmteile ins Review oder schlimmstenfalls ins fertige Produkt gelangen. Die Programmiereinweisungen umfassen dabei alle Teile der Software. Sie reichen vom Dateinamen über die Art der Dokumentation bis hin zu Vorgaben zu Variablennamen.
Bei der Überlegung welche Informationen die Anweisungen enthalten sollen, erachte ich die folgenden Anhaltspunkte für sinnvoll. Für eine strukturierte Herangehensweise lässt sich eine erste Unterteilung in Quellcode und Kommentare vornehmen. Beim Quelltext können die Vorgaben funktioneller oder formeller Natur sein.
|
|
| Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer E-Mail: madzar@medtech-ingenieur.de Tel.: +49 9131 691 240 |
|
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf. |
|
Bei Kommentaren werden die Sprache, der minimale Inhalt und die Positionierung festgelegt. Beispielhaft ist hier: Eine jede Funktion muss kommentiert werden. Dieser Kommentar muss eine kurze Funktionsbeschreibung enthalten und alle übergebenen Parameter beschreiben. Bei der Kommentierung kann auch die Verwendung eines Werkzeugs vorgegeben werden. Mit Doxygen existiert ein sehr gutes und kostenloses Werkzeug, welches aus den in Kommentaren verwendeten Schlüsselwörtern eine druckbare Dokumentation des Programmcodes erzeugt.
Funktionelle Vorgaben für den Quellcode umfassen Forderungen an die Funktionen, Datentypen und Operatoren. So sollen bestimmte Funktionen, welche den Code schwer lesbar machen verboten werden (goto(), komplizierte Konstrukte mit De- und Inkrementen). Des Weiteren lohnt es sich, die zu benutzenden Datentypen einzugrenzen. Zum Beispiel macht die Verwendung der Datentypen aus stdint.h die Größe und den Wertebereich unabhängig vom Zielsystem.
Bei den formellen Vorgaben für den Quellcode handelt es sich um das äußere Erscheinungsbild. Hier werden Forderungen wie das Einrücken per Leerzeichen statt Tabulator, das Klammern von Funktionen und die Benennung von Konstanten, Variablen, Funktionen und anderen Attributen festgehalten. So erleichtert es die Zuordnung von Funktion zu Modul ungemein, wenn der Modul-/Klassenname als Funktionspräfix verwendet wird.
Ausführlich kommentierter und „sauberer“ Code lässt sich leichter wiederverwenden, an einen anderen Programmierer übergeben und warten. Denn eine Funktion deren Aufgabe genau bekannt ist und deren benötigte Parameter beschrieben sind, ist einfach zu verstehen und somit einzusetzen.
Und allgemein lässt sich doch sagen: Es macht mich als Programmierer doch auch stolz, wenn man ein schönes Stück Code geschrieben hat und beim Review oder vom Kunden ein Kompliment dafür erhält ;)
Ein schwieriger Punkt ist natürlich der Umfang der Richtlinien. Die von mir erstellten Richtlinien umfassen 30 Seiten. Zusätzlich bietet es sich an, eine Zusammenfassung, die eine (DIN A4) Seite nicht übersteigt zu erstellen. Die Zusammenfassung kann als kompakter Merker am Arbeitsplatz dienen. Die Zusammenfassung ist unten im Bild zu sehen und kann als PDF heruntergeladen werden. Wer Interesse hat an der kompletten Richtlinie, kann sich einfach bei mir melden.
Programmierrichtlinie C/C++ (Übersicht)
Programmierrichtlinien Übersicht als PDF zum Download
Was denken Sie über das Thema Programmierrichtlinien? Sind sie nötig, welche Erfahrungen haben Sie zum Thema und wo sehen Sie die Probleme oder Schwachstellen bei der Erstellung und Einführung in Unternehmen? Ich würde mich sehr über eine Kontaktaufnahme freuen, natürlich, auch wenn es um Kritik, Anregungen oder Fragen zum Thema geht. Wer Interesse hat an der kompletten Richtlinie, kann sich einfach bei mir melden.
Viele Grüße
Benjamin Eichinger
