Unterschiedlich einheitlich: Coding Standards

Coding Standards sind für Entwickler ein wichtiges und bisweilen auch ein leidiges Thema. Insbesondere im Open Source-Bereich ist es wichtig, dass bestimmte Konventionen eingehalten werden, um Wildwuchs zu verhindern. Wir werfen am Beispiel von Magento 2 einen praxisnahen Blick auf die mit Coding Standards verbundenen Vorteile und Schwierigkeiten sowie auf nützliche Tools.

Was sind Coding Standards?

Als Coding Standards werden im Bereich der Software-Entwicklung bestimmte Konventionen für die formale Gestaltung des Codes bezeichnet. Denn während die syntaktische Struktur von Quellcode durch die jeweils eingesetzte Programmier- oder Skriptsprache – weitgehend – eindeutig vorgegeben ist, bleiben für die Formatierung von Code schließlich noch vielfältige Möglichkeiten nebeneinander bestehen. Welche Zeichencodierung wird verwendet? Mit welchem oder welchen ASCII-Zeichen werden Zeilenumbrüche codiert? Wann werden Zeilen umgebrochen? In welchen Fällen werden Zeilen eingerückt? Mit Tabulatoren oder mit welcher Anzahl von Leerzeichen? Wo werden Leerzeilen eingefügt? Wie genau werden Kommentare dargestellt? Auf diese und weitere Fragen wird jeder Entwickler im Hinblick auf seinen persönlichen Stil je eigene Antworten geben können. Aber wenn mehrere von ihnen gemeinsam an einem Projekt arbeiten, wird schnell sichtbar, dass hier unterschiedliche Ansätze nebeneinander bestehen, so dass der Quellcode im Zweifelsfall ein uneinheitliches Erscheinungsbild erhält.

Um gerade in komplexen Open Source Projekten, etwa in der Arbeit an einem gemeinsam mit der Community entwickelten Shopsystem wie Magento, kein heilloses Durcheinander entstehen zu lassen, werden Coding Standards formuliert. Andernfalls lässt es sich kaum vermeiden, dass der Quelltext immer schwerer lesbar wird – von möglichen Problemen bei der Versionierung und dem automatischen Parsen von Code ganz zu schweigen. In den veröffentlichten Coding Standards, den für alle am Projekt beteiligten Entwickler gültigen Richtlinien, wird genau festgelegt, in welcher exakten Form welche Code-Elemente darzustellen sind. Wenn alle sich an diese Vereinbarung halten, hat der gemeinsam erarbeitete Quellcode schließlich eine einheitliche Form.

Wie sieht es in der Praxis aus?

Wo Coding Standards formuliert worden sind, scheint zunächst einmal alles klar zu sein. Für jeden fraglichen Aspekt der Gestaltung des Quellcodes sind eindeutige, möglichst durch anschauliche Code-Beispiele flankierte Antworten formuliert worden und alle wissen, wonach sie sich richten müssen. Allerdings gibt es in der Praxis erfahrungsgemäß zwei schwerwiegende Probleme, die sich mit den Begriffen Interferenz und Inkonsequenz bezeichnen lassen. Denn zum einen interferieren gerade bei sehr großen Projekten, an denen unterschiedliche Firmen mit je eigenen Coding Standards beteiligt sind, oftmals mehrere nicht restlos kompatible Regelwerke miteinander. Und zum anderen werden Coding Standards oftmals leider nicht konsequent umgesetzt.

Beispiel: Magento 2

Ein sehr ambitioniertes Open Source Projekt, das in der täglichen Arbeit unserer Entwickler eine sehr große Rolle spielt, ist Magento 2. Das Shopsystem wird in enger Zusammenarbeit mit der Community entwickelt, was Magento zuletzt auch wieder verstärkt vorantreibt. Damit die vielen beteiligten Entwickler in aller Welt wissen, wie genau sie ihren Code formatieren müssen, hat Magento umfangreiche Coding Standards für Magento 2 formuliert.

Aber da an Magento Open Source neben dem Hersteller nicht nur freie Entwickler mitarbeiten, sondern auch viele größere und kleinere Firmen, die Themes, Extensions oder Sprachpakete entwickeln und die Weiterentwicklung des Magento Cores unterstützen, entstehen hier schnell potenzielle Interferenzen zwischen firmeninternen Standards und den Richtlinien von Magento. Oder zwischen den jeweiligen Coding Standards unterschiedlicher Firmen innerhalb des Ökosystems.

Und auch im Hinblick auf das Problem der Inkonsequenz können wir aus eigener Erfahrung sagen, dass in der Magento Entwickler-Community längst nicht immer, überall und von allen die Magento Coding Standards eingehalten werden. Leider ist es vielmehr so, dass inkonsistent formatierter Code dazu führt, dass der offizielle Quellcode von Magento die Qualitätstests in eigens zu diesem Zweck entwickelten Analysetools (sogenannte Code Sniffer) nicht besteht. Es gibt also klare Regeln und auch sehr nützliche Werkzeuge (etwa PHP_CodeSniffer mit dem ECG Magento Code Sniffer Coding Standard für Magento 2) für die Überprüfung des Codes auf Konformität mit detailliert ausformulierten Regeln – und doch lassen sich Coding Standards in der Praxis nicht zuverlässig durchsetzen.

Nichtsdestoweniger: Coding Standards sind unverzichtbar!

Auch wenn die Erfahrung zeigt, dass Coding Standards nicht überall miteinander kompatibel sind und auch nicht immer konsequent eingehalten werden, bleibt es ausgesprochen wichtig, sie zu respektieren. Und auch wenn inzwischen im Open-Source-Bereich sehr viele Anbieter von Software eigene Standards definiert haben, denen sich die am Quellcode arbeitenden Firmen und Entwickler letztlich immer unterordnen müssen, bleibt es in vielerlei Hinsicht richtig und wichtig, sich klare eigene Regeln und Richtlinien für die unterschiedlichen Aspekte des Codings zu geben.

Unsere Kollegen von Firegento zum Beispiel haben ihre Coding Standards sehr klug als Ergänzung für einige von den Magento Standards nicht abgedeckten Bereiche formuliert. Und so haben auch wir eigene Standards und Konventionen für die unterschiedlichen Arbeitsbereiche unserer Entwickler festgelegt. In der täglichen Arbeit gilt es dann, sich den jeweiligen Gegebenheiten und Vorgaben anzupassen, denn selbstverständlich gibt es beispielsweise auch für Shopware eigene Coding Standards. Grundsätzlich gilt dabei – und ganz allgemein für die Arbeit am Code – letztendlich vor allem eine Maxime, die Google am Ende des hauseigenen Style Guides für HTML/CSS formuliert: „Be consistent.“