Die 3 Levels der Code-Konsistenz

Artikel vom 16. Oktober 2017, exklusiv für CSS-Tricks. ISSN 1614-3124, #55. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

Als ich jüngst an einem Artikel über benutzerzentrierte Webentwicklung arbeitete, flammte mal wieder das Thema Konsistenz in Code auf. Konsistenz ist ein Faktor für Code-Qualität und einer der Hauptgründe, warum wir Code-Richtlinien brauchen. Interessanterweise kann man drei Grade von Konsistenz festhalten: individuelle, kollektive und institutionelle.

Level 1: Individuelle Konsistenz

Auf grundlegender Ebene und wenn es in unserer Organisation wenig Standardisierung gibt (oder wenn wir alleine arbeiten), bedeutet Konsistenz einfach, mit uns selbst konsistent zu sein. Wir profitieren davon, Code immer auf dieselbe Art zu schreiben.

Wenn wir normalerweise, für uns alleine genommen, unbenötigte Anführungszeichen um Attributswerte auslassen (absolut valid, wie entsprechende Projekte zeigen), sollten wir das immer tun. Wenn wir bevorzugen, die letzte Deklaration einer CSS-Regel nicht mit einem Semikolon zu beenden, dann sollten wir das auch nicht tun. Wenn wir gerne immer Tabs zur Einrückung benutzen, sollten wir das auch immer so machen.

Level 2: Kollektive Konsistenz

Auf der nächsten Stufe, und hier gehen wir davon aus, dass es Code von anderen Entwicklern oder Dritten gibt, bedeutet Konsistenz, dem Code-Stil zu folgen, der dort gilt, wo wir Code anfassen. Wir sollten den Stil respektieren und mit ihm konsistent bleiben, der in den Dateien vorherrscht, die wir bearbeiten.

Wenn wir unseren Kollegen helfen, eine Site zu launchen und ihr CSS modifizieren, formatieren wir den Code so, wie sie es tun. Wenn wir Kerndateien unseres Content-Management-Systems anpacken (mal angenommen, das wäre ratsam), machen wir, was die Urheber taten. Wenn wir für etwas ein neues Plugin schreiben, machen wir das auf dieselbe Art, wie andere solche Plugins geschrieben sind.

Level 3: Institutionelle Konsistenz

Schlussendlich, normalerweise ein Level, das in größeren Organisationen erreicht wird, bedeutet Konsistenz, die Code-Richtlinien einer Organisation zu befolgen (oder aufzustellen). Wenn die Richtlinien etabliert sind und durchgesetzt werden, hat dieser Konsistenztyp die meiste Kraft, um auch Änderungen im Entwicklungsverhalten zu bewirken – individuelle Konsistenz bietet dazu kaum einen Anreiz, und kollektive Konsistenz nur zeitlich befristet.

Wenn wir allgemein mit Leerzeichen einrücken und der Firmen-Styleguide Tabs sagt, benutzen wir Tabs. Wenn unsere Kollegen ihr kleines Projekt starten und wir beim Aushelfen merken, dass ihr Code nicht mit den Unternehmensrichtlinien im Einklang steht, nehmen wir uns die Zeit, den Code zu überarbeiten. Wenn wir was Neues starten, vielleicht auf einer ganz anderen Programmiersprache basierend, starten wir einen Prozess, Richtlinien aufzusetzen und zu standardisieren.

❧ Diese drei Konsistenzstufen schließen sich gegenseitig nicht aus.

In unseren eigenen Angelegenheiten sollten wir zumindest nach Level 1 streben, aber persönlich habe ich gute Erfahrungen damit gesammelt, sich an einen externen Level-3-Standard zu halten (ich befolge Googles HTML- und CSS-Richtlinien mit Ausnahme von Tabs anstatt Leerzeichen) und ein komplementäres Level-1-Regelwerk aufzustellen (wie mit vordefinierter Selektorenreihenfolge).

Wann auch immer wir mit anderen Entwicklern arbeiten, aber es an einem Standard mangelt, sollten wir zumindest Level-2-Konsistenz anstreben, das heißt, ihren Code respektieren. Wenn wir was auf ihrer Baustelle anfassen, machen wir alles so, wie sie es tun.

Wenn wir Teil einer größeren Organisation sind – obwohl »größer« schon bei zwei Leuten starten kann – herrscht dieselbe Idee von Level-2-Konsistenz vor, aber wir können nun daran denken, eigene Standards zu entwickeln, um auf Ebene 3 zu operieren. Dort können wir beide Stufen sogar kombinieren: Die Code-Richtlinien befolgen, aber wenn wir etwas anfassen, dass diese nicht respektiert und wir keine Zeit für ein Refactoring haben, auf die Art weiterschreiben, die sonst im Code gilt.

Aus meiner Erfahrung hilft schon das Bewusstsein dieser Levels, um konsistenteren und damit schon etwas besseren Code zu schreiben.

Wenn Sie mehr über Code-Richtlinien erfahren wollen und dazu ein kurzes, sehr kurzes Büchlein mögen, werfen Sie doch einen Blick auf The Little Book of HTML/CSS Coding Guidelines.

Über mich

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)