colspan=10: Loses zu Code-Richtlinien

Strikt oder liberal? Während Strenge gerne die größten Gewinne für einheitlicheren und hochwertigeren Code verspricht, scheint Toleranz einem besonderen Faktor Rechnung zu tragen: Wir wissen nicht genau, was uns uneinheitlicher Code eigentlich kostet.

Ich selbst war schon früh ein Fan und Verfechter klarer, wenn es sein musste, auch strikter Regeln. Das äußerte sich unter anderem in meiner Arbeit an den Code-Richtlinien von GMX, Aperto und Google (und einem kleinen Buch zum Thema).

Normativ gerne, nicht nur deskriptiv durften solche Richtlinien auch immer sein – das Vorschreiben von Qualitätszielen erschien mir oft sinnvoll. Gerade wenn der Ist-Zustand problematisch war und so die Code-Standards, die man sich selbst oder seinem Team oder seiner Firma gab, schnelle Abhilfe versprachen. (Wiederholte Missachtung im Team wollte ich zu einem Zeitpunkt auch mal dokumentieren, aber glücklicherweise wurde, aus meiner heutigen Sicht, mein Idealismus da gestoppt.)

Vom Verdacht geleitet

Dieser Tage aber bin ich vorsichtiger, und dieser Vorsicht will ich an dieser Stelle, wo es um individuelle technische Ansichten geht, Nachdruck verleihen: Es gibt kaum bis gar keine belastbaren Daten dazu, wie problematisch uneinheitlich, inkonsistent formatierter Code eigentlich ist.

Wir haben immer den Verdacht, dass dieser ja die Effizienz beeinträchtigen und damit Kosten verursachen muss. Und empirisch wollen wir ja auch sagen, dass das Suchen nach bestimmten Stellen im Code einfacher und damit günstiger wäre, würde der Kollege den Code doch genauso schreiben wie wir.

Da ist sicherlich was dran. Nur gibt es – nach meinen Recherchen und Kenntnisstand – keine belastbaren Zahlen. Man hat sich hundert Softwareprojekte angeschaut und die, die über keine Code-Richtlinien verfügten, waren x Prozent langsamer und kosteten im Schnitt y Euro mehr im Jahr. (Oder sind solche Zahlen zu gut versteckt? Ich freue mich über Studien zum Thema.)

Wenn auch anscheinend bislang ebenso wenig erforscht, wissen wir auf der Gegenseite, dass das Erstellen, Etablieren und Durchsetzen von Code-Richtlinien definitiv und sehr gewiss Kosten verursacht. Das ist evident, muss man diese doch erst mal schreiben, kommunizieren, im Tooling irgendwo unterbringen und ihre Befolgung prüfen.

Interessant wäre dann zu auch wissen, was wann der Fall ist: Wann lohnen sich Code-Richtlinien, wann ist ihre Implementierung günstiger als die Akzeptanz der wie auch immer gearteten Ineffizienz, die durch ihren Mangel entsteht?

Fall-zu-Fall-Entscheidung

Das und meine (rein empirische) Beobachtung der letzten Jahre, dass Projekte offensichtlich auch ohne Code-Richtlinien klarkommen können und in solchen Projekten nicht ständig die Welt in Flammen steht, lässt mich aktuell etwas vorsichtiger sein. So habe ich bei sum.cumo, wo ich seit ein paar Monaten zusammen mit zwei Kollegen ein Auge auf das Frontend habe und an technischer Kommunikation arbeite, noch keinen Versuch gestartet, stärker zu reglementieren, wie wir HTML und CSS schreiben. Vielleicht ist ein liberaler Ansatz in Bezug auf Code-Richtlinien sowohl teamseitig als auch ökonomisch betrachtet auch keine schlechte Idee. Pauschal nämlich kann man die Frage, wie man am besten mit Code-Richtlinien arbeitet, so nicht beantworten. ()