Man glaubt gar nicht, wie wichtig Coding Conventions sein können, sobald man mit mehr als sich selbst an einem Projekt arbeitet. Problem: Wir nehmen ein PHP-Projekt mit zwei Entwicklern.

Ein Entwickler ist ein sehr schneller Coder. Er schreibt viel in kurzer Zeit, darunter auch Dirty Hacks, weil’s laufen muss und er schafft es, ein if, ein foreach, ein return und vielleicht noch ein break in eine Zeile zu pressen und das Ganze ohne eine geschweifte Klammer.

Der andere Entwickler ist er der, der alles etwas langsamer angeht, dabei aber mehr nachdenkt und dessen Ergebnis vielleicht dann sogar noch mit Unittests verifiziert wird. Allerdings schreibt er sehr luftigen Code, alles fein säuberlich einrückt, Methoden/Funktionen schön sauber dokumentiert und Klammerungen sind sein Freund. Außerdem geht er nach dem Motto vor: „Es gibt zwei Arten von ifs: Die, die ein else haben und die, die eins bekommen werden“ (danke @ wolfspelz für diesen tollen Spruch).

Nun gibt es bei diesem Szenario ein Problem: der schnelle Programmierer läuft vor den Linienbus und liegt für ein paar Wochen im Krankenhaus und kann keine Fragen beantworten, geschweige denn programmieren. Jetzt muss sich der Vernünftige in diesen fremden Code einarbeiten, kann aber mit dieser kompakten Art und Weise nichts anfangen. Dokumentation gibt es natürlich nicht und überhaupt ist fremder Code eh immer doof.

Letzteren Aspekt kann man nicht wegdiskutieren und ist einfach ein psychologisches Problem. Aber wenn sich beide auf einen gemeinsamen Nenner geeinigt hätten, in dem beide programmieren, wäre es kein Problem, einen Bug schnell zu finden und zu beheben, da alles eine einheitliche Struktur hat. Wichtig sind hier folgende Aspekte:

Welche Klammerungen verwendet man?

Macht man die geschweiften Klammern hinter die Methodenparameter oder am Anfang der nächsten Zeile, z.B.

public function Methode($parameter) {
   Aufrufe;  
}

oder lieber

public function Methode($parameter)  
{  
   Aufrufe;  
}  

Wie sind die Einrückungen zu machen?

Entwickelt ein Entwickler auf einer Console z.B. mit dem VIM, kann es sein, dass dieser bei Tabs die Krise bekommt, weil diese auf eine Weite von 8 Spaces eingestellt sind, beim anderen Entwickler in der IDE aber auf zwei Zeichen stehen. Benutzt man also Tabs oder lieber Leerzeichen? Und wieviele eigentlich?

Wie sind Variablen, Klassen und Funktionen/Methoden zu benennen?

Hier ist auf jeden Fall die Sprache festzulegen (recommended: Englisch 🙂 ), außerdem die Syntax der Variablen, also z.B. benutzt man Unterstriche, Camel-Case (mit gehobenen oder gesenkten Kopf) oder vielleicht sogar die ungarische Notation also mit Prefix

Welche Dokumentationsform wählt man?

Häufig werden z.B. private-Methoden nicht dokumentiert, weil die Klasse gefälligst selbst zu wissen hat, was sie braucht und nach aussen sieht man es eh nicht. Benutzt man Standard-Dokustile wie PHPDoc oder vielleicht doch was ganz anderes?

All diese Dinge dienen nicht nur der Lesbarkeit, sondern auch des Maintaining des Ganzen. Der oben beschriebene Fall, viele Dinge in einer Zeile zu machen, sind beim reverten im SVN von großer Wichtigkeit z.B. beim Anschauen des Diffs einer Revision. Niemand bekommt in einem Projekt einen Preis für’s obfuscating von Quelltexten. Und nur weil der Source undurchsichtig geschrieben ist, wird er nicht automatisch sicherer.

Für manch einen Entwickler mag es eine große Umstellung sein, sich an Konventionen zu halten, aber es lohnt sich wirklich für alle Seiten.