Einleitung

Coding Style Index?

Die Einhaltung eines Coding Standards ist ein wichtiger Bestandteil guter Projektarbeit. Gerade in Open Source Projekten mit vielen Entwicklern wird damit gewährleistet, dass Source Code eine hohe Qualität erhält/behält, weniger Bugs enthält, und einfacher zu warten ist.

Weitere wichtige Faktoren für guten Code:

• übersichtlich
• leicht zu lesen
• leicht zu verstehen
• gut dokumentiert
• Bug-frei
• funktionierend
• getestet
• wiederverwendbar
• einfach wartbar
• leicht erweiterbar
• unterstützt Refactoring
• unterstützt Code Reviewing

Ein Coding Standard unterstützt alle diese genannten Punkte. Neue Entwickler können sich zudem schnell einarbeiten, denn wenn jeder den Code des anderen versteht, kann man auch schnell Bug-Fixes vornehmen, vorhandene Module wiederverwenden oder erweitern.

Das Ziel von leicht verständlichem Source-Code ist erreicht, wenn jedes Mitglied des Teams, jedes Modul aus dem Stehgreif erklären kann. Nicht zuletzt soll jede Arbeit am Projekt, dem Code und der Dokumentation Spaß machen. Je höher der Frustfaktor ist, je unübersichtlicher Strukturen und Code sind, desto höher ist die Wahrscheinlichkeit, das die Arbeit keinen Spaß mehr macht. Das gilt es auf jeden Fall zu verhindern.

Wenn sich ein Projekt an Coding Standards hält, dann sind einige gute Effekte zu beobachten:

• Entwickler können in jeden Code hineinschauen und sofort heraus finden was dort vor sich geht.
• Entwicklungszeiten werden verkürzt und neue Feature können schneller mit in die Applikation aufgenommen werden.
• Code Reviewing wird durch einen Coding Standard und gute Dokumentation erst möglich.
• Die Lebenszeit eines Softwareprojektes wird verlängert und überlebt die Lebenszeit der erfahrenen Entwickler.
• Neue Entwickler können sich schnell einarbeiten.
• PHP-Einsteiger brauchen keinen persönlichen Style enwickeln und diesen bis zum bitteren Ende verteidigen.
• PHP Einsteiger werden davor bewahrt die gleichen Fehler wieder und wieder zu machen.
• In konsistenten Umgebungen werden weniger Fehler gemacht.

Im Stud.IP Coding Standard wird über die üblichen Formatierungsempfehlungen und Namenskonventionen hinaus der gesamte Entwicklungsprozess behandelt und bezieht Themen wie Dokumentation, UML-Diagramme, Tests, Design Pattern, Fehlerbehandlung, etc. mit ein. Das vorgeschlagene Prozessmodell ist der Agilen Softwareentwicklung angelehnt und soll den Ablauf und die Interaktionen der einzelnen Entwicklungs-Phasen verdeutlichen.

Der Visual Style Guide enthält zudem Empfehlungen für die Vereinheitlichung der GUI mit dem Ziel dem Enduser eine intuitive Benutzeroberfläche bieten zu können. Design Elemente sind diesem Style anzupassen.

Einführend geht der Stud.IP Coding Standard auch auf interne Konzepte von Stud.IP ein, wie z.B. Plugins, Templates, PDO, ORM, etc. Es wird sehr empfohlen diese sehr leistungsstarken, higher-level Konzepte bei der Entwicklung zu berücksichtigen. Auch hier gilt: Das Rad muss nicht neu erfunden werden. Genauere Beschreibungen sind der Übersichtsdokumentation zu entnehmen.

Da Stud.IP von einer Vielzahl an Universitäten und Fachhochschulen nicht nur eingesetzt sondern vielfach auch weiterentwickelt wird, ist insbesondere auf die Kapselung von lokalen Besonderheiten zu achten.

Der Stud.IP Coding Standard ist mit dem Datum des in Kraft tretens verbindlich, jedoch führt die Überarbeitung eines Coding Standard immer dazu, dass schon bestehender Source-Code diesen Konventionen nicht genügt. Die Anpassung dieses Source-Codes an die neuen Konventionen ist zwar zu befürworten, jedoch nicht verpflichtend. Jediglich neuer Source-Code sollte dem Standard genügen. Um die Einhaltung des Standards zu garantieren ist es ausdrücklich von jedem Entwickler erwünscht, den Urheber auf etwaige Verletzungen aufmerksam zu machen. Starke Verletzungen können sogar durch Abstimmung in der Core-Group einen Ausschluss des Source-Codes aus dem Release zur Folge haben.

Ein Coding Standard ist im Endeffekt natürlich nur eine Empfehlung und sollte die Kreativität und Freiheit des Entwicklers nicht beeinträchtigen, jedoch sollte dabei auch im Hinterkopf behalten werde, dass ein nicht Einhalten einen guten Grund voraussetzen sollte und dies auch entsprechend dokumentiert werden sollte.