Code-Guidelines, um Fehler einfacher zu erkennen
Ich bin über folgenden Artikel von Joel Spolsky gestoßen: Making Wrong Code Look Wrong . Der Artikel ist schon einige Jahre alt aber, wie ich finde, immernoch aktuell.
Wir Entwickler lieben es, lesbaren Code zu schreiben und immer positiv zu bleiben 😉
Verschiedene Kriterien wie Wartbarkeit, Erweiterbarkeit usw. sind bekannt. Leider kommt es manchmal dazu, dass wir unsauberen Code schreiben. Vor allem, wenn es sich ein Provisorium zur einmaligen Ausführung handelt (welche erfahrungsgemäß am längsten im Einsatz sind).
An dieser Stelle möchte ich auf o.g. Artikel verweisen, da der Artikel einige Hinweise und Tipps enthält. Nun aber zum eigentlichen Artikel meinerseits. Den werde ich allerdings kürzer halten, da viele Punkte im verlinkten Artikel besprochen werden.
Code-Guidelines sollen vor allem eines tun: Einheitlichen Code für verschiedene Entwickler eines Projektes definieren. Sobald mehr als eine Person Code schreibt, können verschiedene Probleme auftreten:
- Variablen sind deutsch statt englisch
- Klammern sind nicht einheitlich
- Funktionsparameter sind nicht eindeutig
- Funktionsnamen sind nicht eindeutig
- Konstanten werden nicht als solche hervorgehoben
- Und vieles mehr…
Es gibt ein interessantes Projekt, was wir mal in der Schule durchgeführt haben. In diesem Projekt ging es darum, dass die Aufgaben und Schritte (und die Funktionsweise des Programms) fest definiert wurden. Durch dieses Projekt sollte jeder auf die Wichtigkeit und Problematik von einheitlichem bzw. nicht einheitlichem Code sensibilisiert werden. Es wurden 4er-Gruppen gebildet. Jeder aus der Gruppe musste jedes der 4 Pakete umsetzen. Allerdings wurde nach jedem Paket der Quellcode von einem Entwickler zum nächsten weitergereicht. Je nach Größe des Projekts können es auch 3 oder 5 Pakete sein. Es ist jedoch darauf zu achten, dass die Pakete nicht zu groß oder zu klein werden.
Das bedeutet, dass in jedem „Endprodukt“ alle 4 Entwickler ihr Paket entwickelt haben (entweder als Beginner oder mitten drin, auf dem vorherigen Stand aufbauend).
In der Theorie sollte dies kein Problem darstellen. Jeder kann Programmieren, Code lesen und schreiben. Es ist hierbei zu bemerken, dass jeder Entwickler einen unterschiedlichen Kenntnisstand hat.
Spätestens nach der zweiten Rotation wurden verschiedene oben genannte Probleme sichtbar. Der erste Entwickler hat die Basis geschaffen. Der zweite Entwickler versucht darauf aufzubauen und hat vielleicht den Code minimal an „seinen Stil“ angepasst. Aufgabe war es, die Funktion zu implementieren. Bestehender Code sollte, wenn möglich, nicht geändert werden. Minimales Refactoring war erlaubt. Der dritte Entwickler musste nun mit zwei Stilen zurechtkommen und seine Weiterentwicklung durchführen. Da jeder seinen eigenen Stil hatte, kam es zum Stocken. Teilweise musste nachgeschaut werden, was eine bestimmte Klasse und Methoden machen (auch mit dem Debugger), um darauf aufzubauen. Es gab Bugs, die im ersten Moment nicht als solche erkennbar waren. Unit-Tests wurden bewusst ausgelassen, um die Problematik der verschiedenen Code-Stile hervorzuheben.
Ich möchte mit diesem Artikel auf einen einheitlichen Code-Stil aufmerksam machen. Durch einen einheitlichen Stil wird zumindest die Schwierigkeit genommen, sich schnell in ein neues Projekt einzufinden.
Jeder Entwickler schreibt Klassen anders oder die Methoden. Wenn alle die gleiche Sprache sprechen und eine einheitliche Grammatik verwenden, wird es für alle Beteiligten erheblich einfacher. Das Unit-Tests zu jedem guten Projekt gehören, sollte selbstverständlich sein 🙂
Es gibt verschiedene Code-Guidelines, welche große Unternehmen öffentlich bereitstellen:
Daher mein Appell und Tipp: Orientiert euch an den Code-Guidelines, welche von größeren Softwareunternehmen bereitgestellt werden (sofern ihr noch keinen Stil habt). Kommuniziert den Stil mit eurem Team/Unternehmen und reduziert so Schwierigkeiten, wenn das Projekt das Entwicklerteam wechselt. Wenn es bezüglich bestimmter Themen (z.B. der Klammersetzung in einer neuen Zeile) Diskussionen gibt, klärt diese und passt eure Guidelines entsprechend an. Die Regeln sind nicht in Stein gemeißelt. Es geht hierbei vor allem um eine Einheitlichkeit und Best-Practices.
Durch verschiedene Tools kann der Code frei formatiert werden, ohne dass der Entwickler großen Aufwand betreiben muss.
Ich möchte an dieser Stelle auf das Buch Clean Code von Robert C. Martin verweisen. Aus meiner Sicht ist das Buch eine Pflichtlektüre für Entwickler.
Habt ihr Guidelines in euren Projekten, an die ihr euch haltet? Was sind eure bisherigen Erfahrungen? Ich freue mich über eure Kommentare.
