Code-Konventionen

Autoren: die Projektgruppe

In unserem Projekt entwickeln mehrere Studenten an der gleichen Software. Damit alle jetzigen und späteren Betrachter der Quellen wenigstens eine optische Grundlage haben, wurden zu Beginn der Arbeiten die nachfolgend aufgeführten Konventionen für die Formatierung von Quelltexten festgelegt.

1. Keine Tabulatoren in den Quelldateien.
2. Umlaute sind nur in Dialogen, Fenstern und Menüs zugelassen.
3. Keine Zeile ist länger als 80 Zeichen. Werden dadurch Umbrüche nötig, sind diese um vier Leerzeichen einzurücken.
4. Kommentare sind über der kommentierten Zeile anzuordnen.
5. Kommentare werden soweit eingerückt, wie der sie umgebende Code.
6. Leerzeichen sind zur Erhöhung der Übersicht reichlich zu verwenden.

  int foo( int par1, double par2 ) {
    int f;
    // diese Funktion macht irgendwas
    f = foo2( 1 );
    // staendig diese Entscheidungen
    if (f == 0) {
      // Funktionsaufruf mit einer Unmenge von Parametern:
      someValue = someFunction( firstParameter, secondParameter,
          thirdParameter, lastParameter );
      f -= someValue / 2;
    }
    return f;
  }

Diese Veranschaulichung enthält eine Reihe weiterer Entscheidungen bezüglich der optischen Gestaltung der Quellen und ist als Referenzmuster anzusehen.

Fortschreibung gemäß Protokoll vom 18.07.02

- Codekonventionen:
   * \-Zeilenumbruch vermeiden
      + "\"-Probleme bei zahlreichen Compilern, z.B. Together
      + Länge von 80 Zeichen/ Zeile veraltet:
         BC 4.5-Compiler, VC++, CVS besitzen keine solchen Beschränkungen mehr
      -> vorhandene (bis auf mehrzeilige #defines) entfernen (Aufgabe: Reinecker)
   * Kernigham/ Ritchie-Methodendeklarationen ersetzen:
      Probleme bei Tools wie Together (Aufgabe: Reinecker)
   * #defines vermeiden, statt dessen const
   * char* und TObjekt**-Arrays meiden:
      besser STL-Objekte (cstring, container) verwenden
   * char[MAXSTRING] sollte unterlassen werden, weil MAXSTRING variieren könnte:
      lieber Konstante für wirklichen Speicherbedarf; besser cstring aus STL
   * BOOL, TRUE, FALSE (Makros !!!) meiden:
      stattdessen die klein geschrieben Varianten verwenden (Aufgabe: ???)
   * friend-Relationen vermeiden (Probleme bei zahlreichen Analysetools):
      statt dessen Accessor-/Mutator-Methoden
   * keine public-Attribute!!!
      besser private oder protected mit entsprechenden Acc.-/ Mut.-Methoden
   * ERGÄNZUNG vom letzten Treffen: die folgenden Ressourcenbezeichner
        IDOK, IDCANCEL, IDABORT, IDRETRY, IDIGNORE, IDYES, IDNO, IDCLOSE, IDHELP
      nicht anders definieren als in Visual C++, WINUSER.H