Projekt Systementwicklung Programmier-, Codier- und Projektkonventionen Prof. Dr. Nikolaus Wulff
Coding Standards Pro: Erleichtern das gemeinsame Bearbeiten des Quellcodes durch verschiedene Teammitglieder. Ermöglichen einen Wiedererkennungseffekt und helfen Fehler schneller zu erkennen. Erleichtern neuen Teammitgliedern den Einstieg. Contra: Werden nicht immer akzeptiert und behindern. Führen dann zu unnötigen Streit. :-( Deshalb: Am Projektanfang verbindlich festlegen! Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 2
Coding Standards cont. Zum Standard gehören nicht nur Formatierungsregeln, sondern auch: Quellcodeorganisation, z. B.: External/System Header Internal Header Typ und Konstanten Definitionen Globale Variablen Funktionen Namenskonventionen für Klassen bzw. Strukturen (ADTs), Variablen und Methoden. Konstanten und Makros in Großbuchstaben Methoden als Verben in Kleinschrift, Klassen/Strukturen als Hauptwörter in Groß. Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 3
Namenskonventionen Das Schema zur Vergabe von Namen für Klassen/Strukturen, Variablen und Methoden muss einheitlich einer definierten und im Projektteam bekanntgegeben Logik folgen. Es darf nicht ein Programmierer eine_methode und ein Anderer einemethode codieren... Ähnliches gilt für die Vergabe von Strukturnamen etc. Es muss klar definiert werden, ob Strukturen per typedef versteckt werden oder nicht. Siehe die Linux Kernel Regeln... Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 4
Projektorganisation Projekte werden i.a. nicht platt im Eclipseprojektverzeichnis hinterlegt, sondern durch Unterverzeichnisse strukturiert: $Projekt/src /gen /lib /html /doc /Debug /Release Sourcen generierte Sourcen Bibliotheken generierte Web-Doku Dokumentation Word & LaTeX Debug Binaries Release Binaries Einige Verzeichnisse liegen unter Versionsverwaltung andere nicht... Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 5
Dokumentation Zu gutem Code gehört eine gute Dokumentation. Java verwendet das Java-Doc Werkzeug, für C/C++ Programme leistet Doxygen gute Arbeit. www.doxygen.org Eclipse plugin http://home.gna.org/eclox Alle öffentlichen Funktionen müssen ausreichend dokumentiert werden. Eine einfache Richtlinie für eine Dokumentation ist: Was wird mit wem (Argumente) wozu (Rückgabewert) gemacht (=> externe Doku). Nicht wie wird etwas gemacht (interne Doku). Dies kommt in interne Methodenkommentare für den Programmierer. Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 6
Eclipse + Doxygen Doxygen Task Installierte Generierte Doku-Site Fehlende Dokumentation Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 7
Generierte Dokumentation Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 8
Werkzeugunterstützung Gute IDE's erleichtern das Einhalten eines Standards durch automatische Formartierung. Eclipse mit shift-ctrl-f Eclipse besitzt mehrere vordefinierte Profile: K&R GNU Projektspezifisch angepasstes Profil So ist es sehr leicht möglich eine einheitliche Formatierung des Quelltexts zu erreichen. Der Streit über geschweifte Klammern ist unnötig Sie müssen aber im Projekt einheitlich sein! Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 9
Referenzen Es gibt nicht den Standard. Im Web existieren zahlreiche Vorlagen für Coding Standards. Ein kleiner Google Auszug mit Anregungen: http://www.gnu.org/prep/standards/ http://www.possibility.com/cpp/cppcodingstandard.html http://www.jetcafe.org/jim/c-style.html http://lxr.linux.no/#linux+v3.3.2/documentation/codingstyle Lesen einer guten Codebasis (z.b. GNU oder Linux Kernel) übt und vermittelt good practices zur eigenen Anregung im Projekt. Die Standards widersprechen sich allerdings teilweise... Prof. Dr. Nikolaus Wulff Projekt Systementwicklung 10