14 Programmierstil

C-Programme können derart kompakt geschrieben werden und bieten andererseits so viele Variationsmöglichkeiten, daß nur durch eine strenge Disziplin bei der Codierung gut leserliche, verständliche und damit wartungsfreundliche, leicht pflegbare Programme zustandekommen. Ein weiterer wichtiger Aspekt des Programmierstils ist die Portabilität, die den Austausch von C-Quellprogrammen auf verschiedenen Systemen gewährleistet.

Verschiedene Software-Teams haben eine Reihe von Programmierempfehlungen gegeben, die Sie bei der Codierung leserlicher und wartungsfreundlicher Programme unterstützen sollen. Die wichtigsten werden in diesem Kapitel vorgestellt. Es bleibt Ihnen allerdings selbst überlassen, ob Sie diese Empfehlungen genau befolgen oder in hier und dort leicht abgewandelter Form Ihren eigenen Programmierstil in C finden.

Bedenken Sie, daß Sicherheit und Klarheit eines Programms (zunächst) wichtiger sind als Schnelligkeit; Tuning sollte als ein additiver Prozeß verstanden werden.
Lassen Sie eine Quelldatei und erst recht eine Funktionsdefinition nicht auf mehr als 500 Zeilen anwachsen. Teilen Sie die Quelldatei und modularisieren Sie Ihr Programm.
Richtwerte für das Auslagern eines Programmteils als gesondert definierte Funktion sind: Sie müssen wegen geschachtelter Kontrolle mehr als fünffach einrücken oder Ihre Funktion ist wesentlich länger als eine (Drucker-) Seite.
Verwenden Sie möglichst nur Standardbibliotheksfunktionen und vermeiden Sie die Verwendung von Systemaufrufen, um systemunabhängig (portabel) zu sein.
Gemeinsame Konstantendefinitionen, Variablen-, Funktions- und Typdeklarationen sollten in eine eigene Datei geschrieben und mit #include eingebunden werden. Eine include-Datei sollte keine Definition von Datenelementen enthalten.
Verwenden Sie keine Pfadnamen in #include-Anweisungen, sondern geben Sie das Verzeichnis mit der -I-Option an.
Verwenden Sie Prototypen (= Funktionsdeklarationen mit expliziter Parameterdeklaration) statt der herkömmlichen Funktionsdeklaration alten Stils. Nur auf diese Weise findet eine Typkontrolle und eventuelle Konvertierung der Parameter statt.
Verwenden Sie die gleichen Parameternamen im Funktionsprototyp und in der Funktionsdefinition.
Beschränken Sie die Anzahl der Parameter auf maximal fünf.
Verwenden Sie 'void *' als generischen Pointertyp und nicht 'char *'.
Folgende Reihenfolge wird bei den lokalen Deklarationen und Definitionen empfohlen: extern-Deklarationen, register-Variablen, auto-Variablen und schließlich static-Variablen.
Benutzen Sie sprechende Namen.
Ein erklärender Kommentar sollte jeder Variablen-, Typen- oder Funktionsdefinition folgen oder vorangehen. Jede Quelldatei und jede Funktion sollte mit einem Kommentar beginnen.
Schachteln Sie Kommentare nicht.
Benutzen Sie - wo möglich - 'short' oder 'long' statt 'int'.
Ein Pointer sollte niemals in einen Nicht-Pointer-Typ umgewandelt werden und umgekehrt.
Definitionen sollten so lokal (z. B. static) wie möglich sein.
Benutzen Sie immer, wenn es möglich ist, die Speicherklasse register.
Beim Rechtsshift ist die Vorzeichenausweitung maschinenabhängig.
Stringkonstanten sollten Sie nicht verändern, verwenden Sie stattdessen ein echtes 'char'-Array.
Selbstdefinierte Namen, die in #define oder einer typedef-Anweisung auftreten, sollten Sie in Großbuchstaben schreiben.
Klammern Sie den defString von #define ein, wenn er zusammengesetzt ist. Das gleiche gilt für Makroparameter, wenn sie in defString als Operand auftreten.
Verwenden Sie keine magischen Konstanten, sondern definieren Sie sie per #define, per enum-Typ oder per const. Sprechen Sie die Konstanten immer symbolisch an.
Legen Sie auch Array-Grenzen durch symbolische Konstanten fest.
Lassen Sie Namen nicht mit dem Unterstrich '_' beginnen, da sie sonst mit internen Bibliotheksnamen kollidieren können.
Externe Variablen sollten Sie immer (nicht nur, wenn Sie es müssen) explizit mit extern deklarieren.
Die lokalen Deklarationen und Definitionen in einer Funktion sollten durch eine Leerzeile von den Anweisungen abgesetzt werden.
Kontrolliert eine Anweisung (if, for usw.) eine oder mehrere Anweisungen, sollten Sie diese um eine bestimmte Anzahl Zeichen (mindestens 3) einrücken. Verwenden Sie (unter UNIX) den C-Beautifier cb.
Ebenso sollten Sie verfahren, wenn eine Anweisung oder ein Ausdruck nicht auf eine Zeile paßt.
Die goto-Anweisung sollten Sie vermeiden.
Geschweifte Klammern sollten Sie in eine eigene Zeile stellen. Zwei Ausnahmen: schließende Klammer bei einer struct-Definition und bei do-while. Das ,,while`` der do-while-Anweisung steht immer hinter der schließenden geschweiften Klammer, damit es nicht mit dem ,,while`` der while-Anweisung verwechselt wird. Aus dem gleichen Grund sollten Sie den Schleifenkörper der do-while-Schleife immer in geschweifte Klammern einschließen, auch wenn er nur aus einer Anweisung besteht.
```
   do
   {
       ...    /* Schleifenkörper */
   } while (...);
```
Fragen Sie Laufvariablen von Schleifen in der Endebedingung nicht auf Gleichheit (==) oder Ungleichheit (!=), sondern immer mit den Operatoren <, <=, > oder >= ab.
Gebrochene Zahlen sollten Sie niemals auf Gleichheit oder Ungleichheit abfragen.
Schreiben Sie einen Vergleich mit 0 explizit aus, obwohl die Logik von C dies auch anders zuläßt.
Jeder binäre Operator (außer ,,->`` und .) sollte rechts und links ein Leerzeichen haben, dagegen sollte jedem unären Operator direkt der Operand folgen.
Obwohl die logischen Operatoren &&, | | usw. mit 'int'-Ausdrücken arbeiten, sollten sie nicht zur Bildung numerischer Ausdrücke verwendet werden.

Zurück zum Inhalt