Spätestens bei der Frage, an welchen Stellen Leerzeichen den Quellcode übersichtlicher machen, und wo sie das Gegenteil bewirken, scheiden sich die Geister genauso endgültig wie an der Frage, wohin genau man die zahlreichen geschweiften Klammern, die den Quellcode durchziehen, denn setzen soll.
Ob nun eine Klammer an der einen oder an der anderen Stelle den Code lesbarer macht, ist ein sehr subjektiver Eindruck. Wichtig allerdings ist, dass alle Beteiligten den Code einheitlich formatieren, insbesondere, wenn IDEs zum Einsatz kommen. Diese „korrigieren“ nämlich gerne mal Weißraum, indem beispielsweise Tabulatoren durch eine konfigurierte Anzahl Leerzeichen ersetzt werden. Das Gleiche gilt, wenn die IDE in bester Absicht etwa Windows- in Unix-Zeilenendezeichen ändert, oder umgekehrt.
Sind nun im Projekt mehrere unterschiedlich konfigurierte IDEs am Werk, kann das schnell dazu führen, dass bei einem Commit in die Versionskontrolle alle Zeilen in jeder Datei als geändert gelten, obwohl der Entwickler selbst aktiv nur einige wenige Zeilen geändert hat. Dies macht es unnötig schwer, später in der Änderungshistorie die tatsächlich relevanten Änderungen zu erkennen.
Es ist also zweitrangig, wie man den Code formatiert. Es ist aber essenziell, dass aller Code im Projekt einheitlich formatiert wird. Genauso wichtig ist es, die Einhaltung der Formatierungsregeln regelmäßig und automatisiert zu überprüfen. Das kann beispielsweise durch den Einsatz eines Werkzeuges wie PHP_CodeSniffer im Rahmen von kontinuierlicher Integration geschehen. Ohne eine automatische Überprüfung werden die Entwickler nur behaupten , dass alle Regeln eingehalten werden, vermutlich sogar nach bestem Wissen und Gewissen.
Jedes Programmierteam muss sich also auf einen einheitlichen Coding-Standard einigen. Dieser sollte deutlich mehr als nur die reine Formatierung von Code beinhalten. Beispielsweise sollte er auch Konventionen zur Benennung von Bezeichnern oder zur Verwendung von Sprachkonstrukten (keine statischen Methoden, keine Singletons, ...) vereinbaren.
Sollte es dem Team nicht gelingen, sich auf einen einheitlichen Coding-Standard zu einigen, so ist dies ein Indikator für ein grundlegendes Kommunikationsproblem im Team. Ein Kommunikationsproblem, das sich durch inkonsistente Formatierung im Quellcode wiederspiegelt.