Ein Knigge für guten Code?

Der Code Codex: Besser programmieren mit fünf Tipps

Ann-Cathrin Klose

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.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

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!

Mehr zum Thema:

10 Tipps: So werden Sie zum richtig guten Programmierer

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose studiert allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz. Seit Februar 2015 verstärkt sie als redaktionelle Mitarbeiterin die Redaktion bei Software & Support Media. Zuvor war sie als freie Autorin tätig und hat erste redaktionelle Erfahrungen bei einer Tageszeitung gesammelt.
Kommentare
  1. Sunshine2017-06-22 20:01:40

    Viele haben auch immernoch nicht verstanden dass ein versionierungssystem keinen Code verliert. Jeder ungenutzte oder kommentierte Code wird von mir mittlerweile gnadenlos gelöscht. Brauche ich ihn nochmal - dafür gibt es git. Ich habe so schon Projekte um hunderte von Zeilen verkleinert und auch tools, die ungenutzten Code erkennen nutze ich sehr gerne. Es lohnt sich auch oft die nach einem beendeten Projekt auf seinen eigenen Code loszulassen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.