Gerade zu Beginn gab es hier noch große Diskussionen:

  • Nehmen wir den Allman-Stil oder rücken wir doch nach Ratliff ein? (Wir haben uns für Allman entschieden.)
  • Setzen wir das schließende PHP-Tag am Ende der Datei oder nicht?
  • Welche Informationen sollen Docblocks enthalten und wo dürfen sie weggelassen werden?

onOffice Coding Style vs. PSR-12

In der PHP-Welt hat sich aber seit 2006 Gott sei Dank(!) einiges getan. Unter anderem gibt es die PHP Framework Interop Group, die seit Jahren PHP Standard Recommendations (PSR) veröffentlicht, um eine gemeinsame technische Basis zu schaffen. PSR-1 ist dabei der Basis Coding Standard. Seit 2012 gibt es mit PSR-2 einen ersten Coding-Style, der 2019 durch den Extended Coding Style Guide PSR-12 ersetzt wurde.

Ähnlich wie in unserem eigenen Styleguide von 2006 wird ausführlich festgelegt, wie PHP-Code formatiert werden sollte. Viele der Punkte entsprechen genau dem, wofür wir uns vor Jahren entschieden hatten – der ein oder andere Punkt aber auch nicht. Zur Einrückung wird eben nicht der Allman-Stil vorgeschrieben und die Einrückung selbst geschieht auch nicht per Tab, sondern über Spaces.

Ist ein Umstieg auf PSR-12 sinnvoll?

Wir haben also ca. 60 Softwareentwickler, die unseren Styleguide kennen und unter Umständen seit vielen Jahren nach diesem Stil programmieren. Wir haben viele tausend Zeilen Quellcode, die teilweise PSR-12 widersprechen. Wieso sollten wir umsteigen?

In der Softwareentwicklung, gerade in einem stetig wachsenden Team, sollte meiner Meinung nach alles automatisiert werden, was sinnvoll automatisiert werden kann. Die Arbeitszeit der Softwareentwickler ist ein begrenztes Gut und der Fokus sollte immer darauf liegen, dass diese Zeit so gut wie möglich eingesetzt wird. Teile unseres Coding Styles konnten nicht automatisiert angewendet werden, weil entsprechende Einstellungen in PHPStorm nicht möglich waren. Weiterhin folgen Tools wie der PHP-CS-Fixer in der Standardkonfiguration zum Beispiel PSR. Zusätzlich kennen immer mehr Entwickler, die neu bei uns beginnen, PSR-12 und müssen sich auf unseren Coding-Style umstellen – eine unnötige Hürde bei der Einarbeitung neuer Kollegen.

Dazu ist PSR-12 deutlich umfangreicher als unser eigener alter Styleguide. In der Vergangenheit mussten wir unsere Vorgaben immer wieder anpassen und erweitern – diese Diskussionen sparen wir uns in Zukunft: Nach dem Wechsel halten wir uns strikt an die Vorgaben aus PSR-12.

Einigung & Durchführung im Team: Der Umstieg

Um das Thema im Team bekannt zu machen, haben wir einmal PSR-12 und insbesondere die Unterschiede zu unserem aktuellen Styleguide im ganzen Entwicklerteam vorgestellt. Das Feedback zur geplanten Umstellung war durchweg positiv, gerade die neueren Kollegen im Team freuten sich über die Rückkehr zur bekannten Code-Formatierung.

Den bestehenden Quellcode haben wir über den bereits genannten PHP-CS-Fixer umformatiert, was ohne Probleme durchgeführt werden konnte. Im Anschluss haben wir eine .editorconfig via VCS deployed, die die Einstellungen in PHPStorm für alle Entwickler auf einen gemeinsamen Stand bringt. Alle Entwickler wurden vor der automatisierten Umstellung aufgefordert, ihre offenen Änderungen möglichst zu committen, um unnötige Konflikte zu vermeiden.

Der größte Diskussionspunkt war der Zeitpunkt der Umstellung. Wir haben monatliche Releases und erstellen eine Woche vor dem Release einen Stable-Branch, in den dann im laufenden Monat nur Bugfixes gemerged werden. Die Umstellung haben wir folglich kurz vor der Erstellung dieses neuen Feature-Branches durchgeführt, um den Zeitraum möglichst kurz zu halten, in dem wir Code-Stände mit unterschiedlicher Formatierung haben.

Im letzten Schritt haben wir noch individuelle Dokumentationen löschen können und verweisen im internen Wiki und unserem Developer Survival Guide jetzt nur noch auf PSR-12 als Standard.

Quellen: