Die 10 Gebote der C-Programmierung

1. Du sollst die Warnungen Deines Compilers nicht ignorieren.
2. Du sollst keinen ausführbaren Code in Header-Dateien schreiben.
3. Du sollst immer Prototypen verwenden.
4. Du sollst, wo immer es möglich ist, "asserts" einsetzen.
5. Du sollst ungültige Zeiger mit NULL kennzeichnen.
6. Du sollst Parameter von Makros immer klammern.
7. Du sollst die Abarbeitungsreihenfolge eines Ausdrucks durch Klammerung verdeutlichen.
8. Du sollst Test-Ausdrücke immer als expliziten Vergleich schreiben.
9. Du sollst den Schleifenrumpf und den if- und else-Zweig immer in geschweiften Klammern {} schreiben.
10. Du sollst nur Standard-C-Datentypen einsetzen und keine eigene typedefs verwenden.

Anmerkungen:

1. Warnungen sind immer potentielle Fehlerquellen!
2. In Headerdateien sollten nur Preprozessoranweisungen (Definements, Makros) und Deklarationen (extern-Deklaration von Variablen, tpedefs, Funktionsprotypen) stehen, auf gar keinen Fall sollten hier Variablen definiert werden.
3. In der guten alten K&R-Zeit (C-Steinzeit) war eines der häufigsten Fehlerquellen der Aufruf von Funktionen mit fehlenden oder/und falschen Datentypen. Als Abhilfe gegen diese Fehlerquelle wurde durch das ANSI-Kommitee Prototypen in den Standard aufgenommen. Prototypen sind die wichtigste Errungenschaft des ANSI-C-Standards, da damit der Compiler endlich die Chance hat, den richtigen Aufruf einer Funktion zu überprüfen.
4. Falls Sie nicht wissen, was ein "assert" ist, sollten Sie in Ihrem C-Handbuch nachschlagen oder sich schnellsten das Buch "Felerfrei Programmieren mit C und C++" besorgen.
5. Ansonsten sieht man einem Zeiger nicht an, ob es ein gültiger oder ungültiger Zeiger ist. Auch der Zugriff über einen "falschen" Zeiger kann gutgehen oder Schaden anrichten, während ein Zugriff über einen NULL-Zeiger fast immer zu einem Programmabsturz führt und damit die Fehlerquelle offenbart.
6. Ansonsten kann es zu falschen Ergebnisse führen

Beispiel:
#define SQUARE(x)      x * x
liefert als Ergebnis für SQUARE(2+3) 11 (2+3*2+3), anstatt 25.
7. Entgegen anderslautenden Gerüchten verursachen zusätzliche (überflüssige) Klammern keinen zusätzlichen Code.
8. Ein beliebter Fehler ist die Verwechslung von "=" mit "==".:
if (x = y) ...
Syntaktisch ist beides möglich. Wenn man sich angewöhnt, immer den Vergleich explizit hinzuschreiben, also
if ((x = y) != 0) ...
wird deutlich, was gemeint ist.
9. Bei späteren Erweiterungen kommt es nicht zu Überraschungen, wenn man immer klammert
10. Ausnahmen sind erlaubt, aber meist machen typedefs den Code nur schwerer zu lesen.

Beispiel:
Farbe rot;
Was ist Farbe für ein Datentyp? Ein enum? Oder struct? Oder vielleicht bloß ein int?