Besserer Code mit fünf Tipps

Der Code Codex: Ein Knigge für guten Code?
Kommentare

Guter Code oder schlechter Code – Definitionen dafür, woran die Code-Qualität erkennbar ist, gibt es viele. Die Lesbarkeit von Code stellt aber häufig ein wichtiges Kriterium dar. An welche goldenen Regeln sollten sich Entwickler halten, um ihren Kollegen das Leben nicht schwerer zu machen als nötig?

Niemand liest oder arbeitet gerne mit schlechtem Code. Das ist anstrengend, das nervt, und es kostet Zeit, die  man eigentlich für etwas anderes verwenden könnte – und wenn es nur das nächste YouTube-Video ist. Stunde um Stunde versuchen zu müssen, den schlechten Code anderer Programmierer zu entwirren, ist einfach ganz und gar nicht schön, da sind sich wohl die meisten Entwickler einig. Insofern kann man durchaus mit Kant dafür argumentieren, dass guter Code eine gute Sache ist:

„Handle nur nach derjenigen Maxime, durch die du zugleich wollen kannst, dass sie ein allgemeines Gesetz werde.“

Oder anders gesagt: Schreib‘ keinen schlechten Code, wenn du selbst keinen schlechten Code lesen willst. Dann bleibt auch mehr Zeit für das YouTube-Video zwischendurch – das man gar nicht mehr so dringend braucht, wenn die Nerven nicht mehr durch schlechten Code strapaziert werden. Aber was ist guter Code denn nun eigentlich genau?

Der Code Codex

Es gibt viele Code Etiketten und Coding Guidelines im Web und noch mehr Ratschläge dafür, wie richtig guter Code aussehen soll. Manchmal erinnern diese Zusammenstellungen dabei jedoch ein wenig an die viel beschworene Netiquette. Die Meisten von uns brauchen dieses Regelwerk nicht – und die, die sich nicht von selbst an diese grundlegenden Regeln des Miteinanders halten, interessieren sich auch nicht für die Netiquette.

Schlussendlich hat aber jeder so seine Schwächen und ist sich vielleicht gar nicht so sicher, was denn nun ein guter Coding-Stil wäre. Manches schleicht sich im Arbeitsalltag einfach ein, andere Ideen entstammen vielleicht einer spezifischen Situation, in der sie gut und richtig waren, sind das heute aber nicht mehr. Ein Abgleich des eigenen Stils mit ein paar übergreifenden Ideen von gutem Code kann also eigentlich nicht schaden, oder?

1. Code gut kommentieren

Die erste Regel des Code Codex ist so banal, dass man sie eigentlich in einen Satz fassen könnte: Guter Code enthält gute Kommentare! Und damit ist das Thema dann auch erledigt, oder? So einfach ist es leider doch nicht. Vor allem unter Berufsanfängern sorgt die Frage nach der richtigen Kommentarquote oft für Unsicherheit.

Grundsätzlich gilt, dass Code an sich verständlich sein sollte. Kommentare können zwar auch darauf ausgelegt werden, dass Menschen, die nicht programmieren können, den Code verstehen. Das ist aber in der Regel nicht besonders sinnvoll. Falls der Manager ohne Programmiererfahrung den Code verstehen können muss, sollte eher zu einer DSL gegriffen werden als zu unzähligen Kommentaren im Java-Code. Kommentare sind insofern dort nützlich, wo Code nicht so gestaltet werden kann, dass andere Entwickler ihn sofort verstehen. Auch dann, wenn es darum geht, den Zweck hinter einer Funktion zu dokumentieren, lohnt sich ein Kommentar – das „Warum?“ lässt sich nämlich nicht immer mit im Funktionsnamen oder im Code unterbringen.

Mehr Kommentare sind aber meist nur dann nötig, wenn man mit Assemblersprache arbeitet. Das kann einfach niemand lesen, also muss alles erklärt werden. Vollständig durchkommentierte Code-Abschnitte, bei denen auf jede Zeile Code ein Kommentar kommt, sind ansonsten aber ein Relikt aus den (amerikanischen) Universitäten, wie John Fuex sagt. Dort dienen sie dem Erwerb neuer Fähigkeiten. Im Berufsalltag kann man jedoch voraussetzen, dass die allgemeine Funktionsweise der im Projekt verwendeten Programmiersprachen allen Beteiligten bekannt ist. Nur dann, wenn neue Libraries oder Sprachen verwendet werden, lohnt sich unter Umständen ein Rückgriff auf das akademische Prinzip.

2. Header-Kommentare?

Lange Header-Bereiche oberhalb des Codes mit vielen Informationen erfreuen sich keiner allzu großen Beliebtheit mehr. Versionsgeschichten, Autoreninformationen und Co. sollten nur dann dort vermerkt werden, wenn keine Version Control verwendet wird. Git und Konsorten erfassen diese Informationen automatisch und übersichtlicher als die einzelnen Files des Projekts. Dort sind die Infos nämlich zumeist eh aufgrund der Zeilenzahl außerhalb des Sichtbereichs zu finden und somit nur mit viel Scrollarbeit nutzbar.

Wenn erst einmal ein solcher Header existiert, fühlen sich jedoch viele Entwickler verpflichtet, der Tradition ihrer Vorgänger am Projekt zu folgen und verwenden unnötig viel Zeit darauf, diese zusätzliche Dokumentation durchzuführen. Die einzige Ausnahme stellen Projekte dar, deren Kommentare automatisch ausgelesen und in eine Dokumentation überführt werden. Auch hier muss nicht immer die Versionsgeschichte erfasst werden; es kann aber sinnvoll sein, Informationen zu verwendeten  Tools und Sprachversionen auf diese Weise zu erfassen.

3. Die richtigen Namen finden

Wie vermittelt man aber, was Code tut, ohne es einfach in einen Kommentar oder den Header zu schreiben? Dazu benötigt man gute Namen im Code: Die Namen sollen ausdrücken, was der Code tut, ohne selbst zum halben Kommentar zu verkommen. Kurze, bündige Formeln und klare Ausdrücke sollten gefunden werden – und wenn das nicht möglich ist, muss vielleicht der Code überdacht werden. Wer gar nicht so genau ausdrücken kann, was sein Code macht, hat nämlich unter Umständen noch nicht die beste Lösung gefunden. Außerdem sollten Namen konsequent einem Schema folgen: Ob CamelCase oder Präfix hängt natürlich auch von der gewählten Sprache ab. Wo Entwickler aber die Wahl haben, sollten sie sich auf eine Form der Namensgebung festlegen.

In jeder Programmiersprache gibt es natürlich auch erlaubte und nicht erlaubte Namen für Klassen, Funktionen und Co. Wer einfach mal einen Namen festlegt, ohne auf diese Regeln zu achten, muss am Ende unnötig viel Aufwand beim Debuggen betreiben. Außerdem sollte man auf Deutlichkeit achten. Abkürzungen in Namen sind keine gute Idee, wenn es sich nicht um allgemein anerkannte Standardausdrücke handelt. Wer eigene Abkürzungen einführt, kann sich sicher sein, dass die Kollegen Probleme damit haben werden – zu kurz darf der Name also nicht werden. Zu lange Namen sind jedoch auch nicht gut. Der Name sollte keine Informationen enthalten, die bereits durch den Code ausgedrückt werden. Er sollte also beschreiben, was der Code tut und nicht (nur) benennen, wie er es tut.

4. Community- und Sprach-Standards beachten

Apple hat (unter anderem) Guidelines für die Arbeit mit Objective-C im Allgemeinen und dem Cocoa API im speziellen veröffentlicht; für PHP gibt es gleich mehrere Coding Conventions. Auch für Java gibt es einige Vorschläge dazu, wie guter Code auszusehen hat. Ähnliche Standards und Empfehlungen existieren natürlich auch für andere Sprachen! Und die sollte jede Entwickler für seine bevorzugten Programmiersprachen kennen. Ohne geht nichts.

Diese Vielfalt der Konventionen und Regeln bedeutet aber auch, dass es keinen einzelnen Codex für guten Code geben kann. Manches, wie der Verzicht auf zu zahlreiche Kommentare, ist sicherlich auf viele Sprachen anwendbar. Andere Konventionen können sich aber stark voneinander unterscheiden. Insofern sollten Entwickler immer im Kopf haben, dass man sich nicht unbedingt beliebt damit macht, hergebrachte Konventionen zu missachten. Die Kollegen kennen die Konventionen der Sprache des Projekts nämlich mit Sicherheit auch. Eine wichtige Ausnahme stellen natürlich die Projektstandards dar. Wenn ein Projekt eigenen Konventionen folgt, müssen die allerdings gut dokumentiert werden – sonst wird der Code schwer verständlich für später übernehmende Kollegen.

5. Dokumentationen schreiben

Das agile Manifest schlägt allerdings vor, dass man gute, verständliche Software entwickeln solle, statt ewig zu dokumentieren, was man alles nicht so gut gelöst hat. Warum also gehören Dokumentationen nun zum Code-Codex? Ganz einfach: Es kommt darauf an, was dokumentiert wird und wie man es macht. Auch die Autoren des agilen Manifests hatten wohl eher nicht im Sinn, dass gar nichts mehr dokumentiert werden soll. Der User soll am Ende ohne große Dokumentation auskommen – für Kollegen, die den Code vielleicht noch jahrelang pflegen müssen, sind Dokumentationen allerdings wirklich hilfreich.

Das gilt für eigene Konventionen und Naming-Stile; das gilt aber auch für den Zugriff auf eigene APIs und den allgemeinen Aufbau des Projekts. Eine gute Dokumentation kann den Unterschied zwischen einer problemlosen langfristigen Wartbarkeit und dem großen Frust der Kollegen ausmachen. Gute Kommentare im Code sind dabei ein wichtiger Bestandteil der Dokumentation. Niemand will erst lange nachlesen müssen, bevor er weiß, was eine Funktion macht. Das Gesamtbild, inklusive noch  offener Probleme und nicht optimal gelöster Implementierungen, sollte jedoch definitiv in einer eigenen Dokumentation erfasst werden um einen schnellen Einstieg zu ermöglichen.

…und noch einiges mehr

Natürlich hat jeder Entwickler und jedes Team einen eigenen Code Codex. Dazu gehört unter anderem auch, dass keine Bugs einfach im Code belassen werden, ohne etwas zu sagen; dazu gehören sinnvolle und stringente Einrückungen des Codes und die Begrenzung der Zeilenlänge. Auch regelmäßige Code Reviews gehören natürlich zum Code Codex: Vier Augen sehen mehr als zwei, sodass eine Review dabei hilft, die Qualität des Codes zu steigern. Außerdem ist durchaus umstritten, ob  putzige Dinos in den Code gehören. Und dann kommt es noch auf individuelle Faktoren an, die von Projekt zu Projekt und Entwickler und Entwickler verschieden sind. Mit den fünf vorgenannten Tipps lassen sich aber doch bereits einige Fehler vermeiden, die zu schlechtem Code führen können!

Was ist für Euch der wichtigste Code Codex? Lasst es uns per Kommentarfunktion wissen!

Lesetipp: Knigge für Softwarearchitekten – Reloaded

Knigge-fuer-Softwarearchitekten_ReloadedWer noch mehr über Softwareentwickleretiquette lernen möchte, dem empfehlen wir den „Knigge für Softwarearchitekten – Reloaded“ von entwickler.press. Die Autoren Peter Hruschka und Gernot Starke zeigen Ihnen unterhaltsame und praxisgerechte Wege zu besseren Softwarearchitekturen – wirkungsvoll, zeitlos und technologieneutral! Sie finden typische Verhaltensmuster von Softwarearchitekten, gute und schlechte. Aus Erfolgsmustern lernen Sie, bessere Systeme zu konstruieren und effektiver zu arbeiten. Aus den „Anti-Patterns“ leiten Sie Abhilfen gegen schlechte Architekturmanieren ab. Ein besonderes Augenmerk liegt auf der Evolution und der Änderung von Systemen.

Aufmacherbild: Max und Moritz (Busch) 040.png (Public Domain)

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -