Die folgende Liste enthält eine ungeordnete Sammlung von Tipps, die sich aus der Erfahrung vieler Jahre des Programmierens ergeben hat. Vielleicht kann der eine oder andere Leser auch von dieser Liste profitieren.
Ungeordnete Programmiertipps |
Schreib klare, lesbare Programme; versuche nicht, allzu 'clever' zu sein. |
Schreib im Kommentar auf, was du meinst - einfach und direkt. Kommentare sind keine Belletristik. |
Sofern vorhanden und verfügbar, benütze Bibliotheken. |
Vermeide globale, temporäre Variablen. |
Versuche nicht die Effektivität eines Programms auf Kosten der Klarheit zu steigern. |
Schreibe nie zwei Anweisungen in eine Zeile. |
Ersetze wiederholte Ausdrücke durch Unterprogramme. |
Verwende Klammern um Zweideutigkeiten zu vermeiden. |
Erfinde unverwechselbare Variablen- und Prozedurnamen (nicht 'EC' oder 'HJ13X_A', sondern z.B. 'ErrorCode'). |
Unterprogramme sollen deutlich gekennzeichnet werden, so dass die Unterprogrammköpfe deutlich ins Auge fallen. |
Vermeide unnötige Verzweigungen. |
Verwende nur die guten Eigenschaften einer Programmiersprache, vermeide die Verwendung der schlechten Eigenschaften (z.B. 'GOTO' in Pascal'). |
Ersetze nie logische Gleichungen durch bedingte Verzweigungen. |
Benutze den 'Telefon-Test' für die Lesbarkeit (kann das Programm durchs Telefon mündlich weitergegeben werden ?). |
Verwende 'BEGIN..END' und Einrückungen um Statements zu gruppieren. Die Einrückungen sollen die innere Logik des Codes widerspiegeln. |
Verwende 'IF..ELSE' um klar zu machen, dass es nur eine Alternative im Programmfluß gibt (geben darf). |
Verwende 'WHILE..DO', 'REPEAT..UNTIL' oder 'FOR..NEXT' für Schleifen (niemals 'GOTO'). |
Ordne alle Unterprogramme so, dass logisch verwandte Teile auch im Quellcode nahe beieinander stehen. |
Benütze 'IF..ELSE IF..ELSE IF..ELSE ...' oder 'CASE' für Mehrfachverzweigungen |
Schreibe für jedes Unterprogramm einen Kommentar-Kopf, indem die Eingangs- und Ausgangsparameter und die Funktion beschrieben sind. |
Verwende niemals ELSE GOTO oder ELSE EXIT |
Überarbeite den ersten Entwurf eines Programms nach mindestens 24 Stunden Pause. |
Verwende Unterprogramme und Funktionen. |
Dokumentiere das Zusammenspiel von Modulen und Unterprogrammen. |
Dokumentiere ausführlich die Datenstrukturen. |
Schreibe Unterprogramme die für sich alleine nur mit den übergebenen Parametern funktionieren. |
Flicke nie an schlechtem Code herum - schreibe ihn von Grund auf neu. |
Entwerfe und teste ein großes Programm in kleinen Schritten. Mache immer zuerst einen Top-Down-Entwurf. |
Überprüfe Eingaben auf Plausibilität. |
Stelle sicher, dass Eingaben und Zwischen-Ergebnisse nicht zum Absturz des Programms führen. |
Programmiere defensiv. Überprüfe an kritischen Stellen die Plausibilität der bearbeiteten Daten. |
Gib Fehlermeldungen aus, wenn Fehler auftreten und ermögliche Korrekturmaßnahmen. |
Beende die Fehlersuche nicht nach dem ersten gefundenen Fehler. |
Beauftrage andere mit einem Test des Programms. |
Verwende Compiler, die über einen Debugger verfügen. |
Jeder Anweisungsblock darf nur einen Ausgang haben (niemals 'GOTO' oder 'EXIT' verwenden). |
Teste das Programm mit den möglichen Grenz-Eingangswerten. |
Schreibe bei jeder Variablen-Deklaration kurz die Bedeutung in einem Kommentars dazu. |
10.000 * 0.100 ist meist nicht 1.000 !!. |
Verwende nie Fließkommazahlen zum Vergleich auf Gleichheit. |
Mache ein Programm klarer statt schneller. |
Wenn du ein Programm beschleunigst, stelle sicher, dass es nachher noch funktioniert. |
Laß den Compiler optimieren, der kann das (hoffentlich) besser. |
Stelle sicher, dass der Kommentar immer am laufenden ist. |
Schlechter Code wird durch einen langen Kommentar nicht besser. |
Schreib nicht mehr Kommentar als Source-Code. |
Sorge dafür, dass ein Unterprogramm nie länger als etwa eine A4-Seite ist. |
Mache nie eine Änderung oder Erweiterung fünf Minuten vor einem Termin. |
Stelle sicher, dass alle Variablen zu Beginn des Programms initialisiert werden. |
Versuche bewußt, das Programm durch blödsinnige Eingaben zum Absturz zu bringen. |