Ein Länzchen für die Schönheit

Eine Lanze für etwas zu brechen heißt, Partei für eine Sache zu ergreifen bzw. für eine Sache in eine Schlacht zu ziehen.

Programmieren macht einen Heidenspaß – Fehlersuche nicht. Es gibt Informatik-Studenten, die der Meinung sind, dass es mindestens ein Seminar zum Thema Flüche geben sollte. Wer schon einmal einen Fehler gesucht und nicht gefunden hat, geht durch eine der unzähligen Programmierer-Höllen.

Wenn man gerade keinen Fehler sucht, macht’s aber Spaß.

Um die Höllenqualen zu minimieren, sollte man alle Waffen einsetzen, die man hat. Einige behaupten, im Krieg und in der Liebe sei alles erlaubt.
Fehlersuche ist Krieg.

Die mit Abstand beste Waffe gegen Programmierfehler ist das Hirn des Programmierers. Nicht nur, weil da die Flüche wohnen, sondern auch, weil man da trainierenen kann, wie man Fehler vermeidet.

Die zweitbeste Waffe ist das Schreiben von „schönem“ Code.

Was schöner Code ist, hängt davon ab, von wo aus man ihn betrachtet. Vom Standpunkt eines Fehlervermeiders aus gesehen sollte Code so geschrieben sein, dass man dessen ungefähre Struktur schon dann erkennt, wenn man den Code selbst noch nicht lesen kann.

Mit anderen Worten:

Wenn man den Code ausdruckt und aus ein paar Metern Entfernung betrachtet, sollte man den groben Aufbau schon dann erkennen können, wenn man zum Lesen einzelner Befehle noch zu weit weg ist.

Um das zu erreichen, sind nur wenige Dinge zu beachten:

• Code nicht breiter als 80 Zeichen.
  Das hat damit zu tun, dass viele Nadeldrucker im Textmodus nicht mehr als 80 Zeichen in eine Zeile schreiben können. Dass aktuelle Drucker mit vielen Punkten pro Zoll drucken und mit passender Schriftart auch hunderte Zeichen in eine Zeile bekommen, freut zwar den, der einen solchen Drucker hat, aber wer nicht in einer halbwegs erträglichen Qualität lesen und herumkritzeln kann, ist aufgeschmissen. Text in 4 pt Größe macht zwar die Zeilen im Ausdruck schön kurz, aber das Lesen solcher Zeilen führt geradewegs in eine der oben erwähnten Höllen.
• Funktionen sollten vollständig auf eine Bildschirmseite passen.
  Sonst muss man sich nämlich merken, was gerade nicht zu sehen ist.
• Gestrüpp aus dem Weg räumen.
  Soll heißen: Codeteile, die sich in Funktionen zusammenfassen lassen, verschiebt man entweder an Stellen, wo sie nicht stören, oder man legt diese in eigenen Dateien ab. Im Arduino-Editor legt man hierfür einen neuen „Tab“ an. Die Datei nennt man am besten so wie die Funktion – das erleichtert das Finden der passenden Datei auf Dateisystem-Ebene.
• Einheitliche Einzüge und Klammersetzung.
  Ich habe mir angewöhnt, je Einrückungs-Ebene zwei Leerzeichen zu verwenden. In Ausnahmefällen genügt auch mal eins. Hinsichtlich geschweifter Klammern habe ich mir angewöhnt, sie in eigene Zeilen zu setzen. Dann stehen zusammen gehörende öffnende und schließende Klammern übereinander, was meiner Meinung nach sehr beim Lesen hilft.

Wer sich ein wenig Arbeit ersparen möchte, kann fürs Grobe die automatische Formatierung der IDE benutzen (Strg-T).

All das hilft zwar nicht besonders, wenn man logische Fehler im Code hat, aber auch für die Jagd auf solche Fehler gibt es sehr gute Waffen – zum Beispiel das Anfertigen eines Programmablaufplans.

Hier kann man eine kleine Code-Vorlage herunterladen, die ich mir gemacht habe. Mit dem „Lineal“ kann man jederzeit kontrollieren, wie breit der Code ist.

Apropos Schönheit: Hässliche Dinge gibt’s ja wohl genug.

Weiter zu: Kleine Knopfklasse