• Wähle beim Programmieren immer den einfachsten Weg.
• Programmiere so einfach, dass Kommentare überflüssig sind.
• Vermeide tiefe logische Verschachtelungen.
• Vermeide komplexe Pointer-Konstruktionen.
• Sei in allem was du tust, konsistent.
• Benutze ein einheitliche Einrückungsschema.
• Sei konsistent bei Namensgebung von Variablen und Funktionen.
• Vermeide nach Möglichkeit die Aufteilung von Logik über verschiedene Ort (Funktionen, Module)
• Mach es gleich beim ersten Mal richtig.
• widerläuft das nicht dem WerdenWirNichtBrauchen? WerdenWirNichtBrauchen ist eine Regel mit der der Erfahrene das Überflüssige der Unerfahrenen abweist. Der Erfahrene macht das Richtige ohne Mühe. Das Richtige zu tun kann nie falsch sein.
• Schreib keine Kommentare mit Selbstverständlichkeiten.
• Vermeide Funktionen mit Seiteneffekten (alle Veränderungen sollen über Parameter und Returnwerte stattfinden)
• Dies gilt nur für funktionales Programmieren. Warum? vielleicht, weil bei Objekten die Seiteneffekte meist der primäre Grund einer Funktion sind? Die Veränderung von Objekten durch Methoden ist kein Seiteneffekt. Jeder Methodenaufruf enthält technisch eine Objektreferenz als Parameter. Seiteneffekt ist, wenn eine Funktion den Zustand des Programmes verändert. Somit ist jede Änderung eines Objektes ein Seiteneffekt - unabhängig davon, wie die Funktion/Methode das geändert Objekt findet. Funktionen, die keine Seiteneffekte haben, änderen nichts, sie lieefern nur ein Ergebnis. (sin(1) ist eine seiteneffektfreie Funktion, f.close() ist keine)
• Programmiere nach Möglichkeit fehlertolerant
• Im Gegenteil: mach bei jedem Fehler so viel Krach, dass man den Fehler nicht tolerieren kann und ihn beheben muss aber unterscheide Eingabe- und Programmierfehler Warum soll Eingabefehler nicht tolerant abgefangen werden? Eingabefehler schon, die kann man nicht beheben. Programmierfehler nicht, die soll man behenen. Warum soll das Schließen eines nicht-offenen Files einen Fehler auslösen? Wenn es kein Fehler ist, dass haben wir nichts zu tollerieren, wenn es ein Fehler ist, dann sollte er behoben werden
• Fehlertolerant programmieren und das oben genannte "Krach machen" sind kein Widerspruch. Fehlertoleranz zeichnet sich durch Erkennung möglicher Fehlerquellen aus, was eben auch Programmierfehler beinhaltet. Zusicherungen und Invarianten brauchen nicht in Programmabbrüche münden. Es reicht aus, den Fehlerzustand zu erkennen. Kann man die Ursache einkreisen - um so besser!
• Definiere nie mehr als eine Variable in einer Zeile.
• Schreibe nie mehr als einen Befehl in eine Zeile.
• Schreib nur selten Funktionen, die länger als 20-30 Zeilen sind.
• Die durchschnittliche Funktionslänge sollte 10-15 Zeilen nicht übersteigen.
• Vermeide nach Möglichkeit dynamische Allokierungen (falls im System vorhanden)
• Warum? MallocFreeVermeiden
• Verwende nur "standardisierte" goto's (falls vorhanden).
• ...

Anmerkungen

Die Längenangabe für Funktionen oder Module kann nur ein tendezieller Wert sein, da dieser vom gewählten Layout, der Klammernsetzung usw. abhängt. Ein ursprüngliches Motiv - nämlich eine Funktion auf einem Blick auf einem 25-Zeilen-Bildschirm überblicken zu können ist mittlerweile obsolet. Es geht vielmehr darum, dass kleinere, auf eine Aufgabe spezialisierte Funktionen leichter fehlerfrei gemacht und leichter wiederverwendet werden können.

Einwände