Programmierrichtlinien
An dieser Stelle sollen die Richtlinien für das LooPo -
Projekt festgeschrieben werde, damit die einzelnen Programmteile eine
gemeinsame Linie aufweisen.
Der Referenzstand für LooPo steht im Homebereich des Users loopo unter
~loopo/loopo
-rw-rw-r-- 1 ellmenre loopo 1286 Aug 3 15:57 Makefile
drwxrwxr-x 2 wieninge loopo 512 Aug 3 15:08 allocator/
drwxrwxr-x 2 keimer loopo 512 Aug 4 11:46 dependences/
drwxrwxr-x 2 ellmenre loopo 512 Aug 3 15:08 dispo2/
drwxrwxr-x 2 ellmenre loopo 1024 Aug 4 11:41 frontend/
drwxrwxr-x 2 ellmenre loopo 512 Aug 3 16:14 lib/
lrwxrwxrwx 1 ellmenre loopo 14 Aug 3 11:28 loopo -> frontend/loopo*
drwxrwxr-x 2 schuler loopo 512 Aug 3 15:42 scanpars/
drwxrwxr-x 2 wieninge loopo 512 Aug 3 15:08 scheduler/
drwxrwxr-x 2 faber loopo 512 Aug 3 15:07 targgen/
drwxrwxr-x 2 faber loopo 512 Aug 3 15:07 targout/
Jeder hat für sein Projekt ein Unterverzeichnis, in das er von Zeit zu Zeit
einen lauffähigen Stand hineinkopiert. Das jeweils
auszuführende Programm hat (vorerst) denselben Namen wie das
Verzeichnis. Im loopo-Baum darf nie direkt entwickelt
werden, damit das Gesamtprojekt immer funktioniert und die anderen
Projektteilnehmer nicht in ihrer Entwicklungsarbeit behindert werden. Die
Dateien von anderen Projektteilnehmern sowie das Hauptmakefile dürfen nicht
verändert werden.
Das Hauptmakefile definiert einige Pfade und Umgebungsvariablen, die an die
unteren Makefiles weitergegeben werde (z.B. Compilername). Daher sollte man
die Makefiles in den Unterverzeichnissen nicht direkt aufrufen, sondern
über das Hauptmakefile. Beispiel: nicht cd scheduler; make,
sondern make sched. Wenn Wünsche nach zusätzlichen Einträgen im
Makefile bestehen, trage ich die gerne ein.
Der vorgeschlagene Vorgang ist, daß dich jeder der Entwickler den
LooPo-Baum in seinen Homebereich kopiert (cd ~loopo; cp -r loopo
~) und dort dann entwickelt. Es ist sicherlich sinnvoll, während der
Entwicklung ein version control system zu benutzen ( siehe dazu man
rcs).
Weitere allgemeine Regeln:
- Sämtliche Namen sowie alle Kommentare im Code auf Englisch
- Jede nichttriviale Funktion/Struktur kommentieren
- Definitionen in headerfiles schreiben
- Übersichtlichkeit anstreben, d.h. große source-files aufspalten
- möglichst große Datenkapselung mit C++-Klassen anstreben
- möglichst wenig C-Funktionen benutzen, eher auf auf libg++ ausweichen
- evtl. bei Strukturierung des Codes an den GNU Programmierrichtlinien orientieren
Nils Ellmenreich