Sauberes Programmieren

written by Martin HĂ€cker on

(zu Return to Innocence von Enigma)

Es ist wirklich erstaunlich wie viel schwieriger es ist saubere Programme zu schreiben wenn mehr Leute an der Konstruktion beteiligt sind.

Nehmen wir zum Beispiel drei Leute. Einer hat vorher viel C++ progirammiert. Ganz selbstverstĂ€ndlich ist fĂŒr ihn das Paradigma geworden, das man Accessoren -getVar und Mutatoren -setVar:aValue nennt.

Und schon mischt sich im System der Namens-Salat. Und das ist noch keine große Sache. Von sich aus besteht keinerlei Einheitlichkeit, wie wer seine Variablen und Funktionen nennt. Wie z.B. heißt eine Klassenmethode zum erstellen eines Objekts? -classname:instanceVarName with:anotherInstanceVarname oder -intentionWithNamedThing:aTypeDescription withAnotherNamedThing:aTypeDescription

Wie geht man mit Prefixen um? Was will man mit Instanzvariablen tun? Wann verwendet man (sinnvollerweise Accessoren und wann direkten Zugriff auf Variablen?

Die Summe dieser kleinen Entscheidungen macht so viel von der (olfaktorischen?) Sauberheit eines Programms aus, das man sich (eigentlich) nicht leisten kann sie dem Zufall zu ĂŒberlassen.

Aber der Overhead das alles vorher festzulegen oder auch nur zu kommunizieren ist gewaltig. Vor allem wenn man weder Refaktoring-Werkzeuge hat die einem die Änderungen erleichtern, noch Unit-Tests die einem die Änderungen absichern, noch Reviews / Pair-Programming die einen zu der Entscheidung helfen was geĂ€ndert werden soll.

Was tun?

Erleichterung finde ich in der Tatsache, das tatsĂ€chlich viele kleinen Entscheidungen kaum oder keine Rolle spielen. Wo die Klammern gesetzt werden, oder wie weit eingerĂŒckt wird ist egal. Man ĂŒberließt diese Unterschiede einfach.

Dazu kommt die Aussage aus dem Big Ball of Mud Paper: Ein Dreckball mag besser sein als gar keine Software.

Ist Sauberkeit also doch ĂŒberschĂ€tzt?