123 Invest Gruppe: Kommentar
Code Codex – ein Garant für gute Codes?
Es gibt kein strenge Definition für einen guten Code, aber eine Reihe von Prinzipien, um Code zu produzieren, der intuitiv verständlich und leicht zu ändern ist. Verständlich bedeutet in diesem Fall, dass der Code von jedem geschulten Entwickler auf Anhieb erfassbar ist.
Ob ein Code gut oder schlecht ist, hängt zum Beispiel von dessen Lesbarkeit ab. Gibt es einen Code-Knigge und wenn ja, was können Entwickler dafür tun, damit ihr eigenes Team und externe Teams keine unnötige Arbeit haben?
Die Komplexität von extern erstellten Codes
Fakt ist: Niemand liest oder arbeitet gerne mit schlechten Texten – nicht anders ist es mit Software Codes. Das ist anstrengend und es kostet Zeit. Den schlechten Code anderer Programmierer zu entwirren, ist einfach ganz und gar nicht schön, da sind sich wohl die meisten Entwickler einig. Insofern liegt die Verantwortung im Team nachvollziehbare Quellcodes zu entwerfen – sogenannten »Clean Code«. Nach Kant argumentiert könnte das heißen:
„Handle nur nach derjenigen Maxime, durch die du zugleich wollen kannst, das sie ein allgemeines Gesetz werde.“
In die heutige Zeit übernommen, würde Kant meinen: „Programmiere keinen schlechten Code, wenn du selbst nicht damit konfrontiert werden willst.“ Unter dem Strich betrachtet, bleibt ganz einfach mehr Zeit, die man mit anderen Dingen verbringen kann. Das ist doch ein gutes Argument, oder nicht? Nun stellt sich aber die Frage, was einen guten Code auszeichnet und was das eigentlich ist.
Der Code Codex – ein Regelwerk im Programmieren
Die Anzahl an Code Etiketten und Guidelines zur guten Programmierung ist lang. Einige Tipps erinnern an ein Regelwerk, in dem es eher um die Online-Netiquette, als um wirkliche Ratschläge zum Code schreiben geht. Das Gute ist, dass die meisten Programmierer diese „Leine“ nicht brauchen und die, die jegliche Regeln missachten, auch kein Interesse an den Grundlagen des Miteinanders zeigen.
Nicht jeder auf den ersten Blick schwer lesbare Code ist eine Böswilligkeit. Manchmal kommt man im Moment der Programmierung einfach nicht auf den besten Coding-Stil oder man folgt seinem Konzept, das sich in einer anderen Situation bewährt hat. Ist es ratsam, den eigenen Stil mit anderen Ideen für gute Codes abzugleichen? Wir denken schon, denn Inspiration kann nicht schaden!
1 | Gut kommentiert!
Eine wichtige Regel im Code Codex ist schlicht und einfach. Ein guter Code ist gut kommentiert. Wäre es allerdings so einfach, gäbe es keine schlechten Codes und keine Herausforderungen, die vor allem Berufseinsteigern Schwierigkeiten und schlaflose Nächte bereiten. Die richtige Quote für Kommentare sorgt manchmal also auch für Unsicherheit.
Prinzipiell muss ein Code vor allem verständlich sein. Mit Kommentaren lässt sich die Codierung für Nicht-Programmierer verständlich machen. Doch wirklich sinnvoll ist diese Maßnahme nicht, sofern es sich nicht um wirklich komplexe Codes mit Kommentaren für andere Entwickler handelt. Vor allem in der Funktionserklärung kann ein Kommentar sinnvoll sein, da es für das „Warum“ in der eigentlichen Programmierung keinen Platz gibt. Um einem Berufseinsteiger oder einem Laien Codes verständlich zu machen, kann der Kommentar noch so gut sein – ohne Sachkenntnis bleibt das Verständnis aus.
Anders verhält es sich mit der Assemblersprache. Hier sind voll kommentierte Abschnitte in den Codes sinnvoll, da die Sprache selbst von den versiertesten Programmierern nicht gelesen werden kann. Diese Methode beruht auf dem Einsatz an amerikanischen Universitäten, wo sie dem Erlernen neuer Fähigkeiten diente. Im Business kann und sollte man voraussetzen, dass jeder am Projekt Beteiligte mit den genutzten Programmiersprachen vertraut ist und dementsprechend keine Aufschlüsselung durch Kommentare benötigt. Bei Neueinführungen von Libraries oder Programmiersprachen besteht eine Ausnahme – hier kann auf das amerikanische Universitätsrelikt zurückgegriffen werden.
2 | Was ist mit Header-Kommentaren?
Elefanten-Headers über dem Code sind out. Vermerke der früher üblichen Informationen sind nur nötig, wenn auf die Version Control verzichtet wird. Mit Git & Co. werden die Infos übersichtlich und vollautomatisch erfasst. Hier erspart man sich einen langen Scroll-Balken, ohne den der Bereich außerhalb des Sichtbereichs nicht sichtbar ist.
Existiert bereits ein langer Header, entscheiden viele Programmierer traditionsbewusst und wenden enorme Zeit für die Dokumentation auf. Ausnahmen sind dabei lediglich in Projekten nötig, bei denen eine automatische Auslesung und Überführung der Kommentare in die Dokumentation erfolgt. Die Erfassung der Versionsgeschichte sollte im Einzelfall geprüft werden – sie ist manchmal sinnvoll, aber nicht prinzipiell notwendig.
3 | Ein passender Name
Wie erfolgt die Vermittlung des Code-Inhalts ohne einen Kommentar im Header? Ganz einfach: Über einen passenden Namen. Kurze Formeln und ein klarer Ausdruck sagen mehr aus als ein langer Kommentar. Sollte sich diese Methode als Unmöglichkeit darstellen, kann das Überdenken des Codes eine Lösung sein. Lässt sich im Namen nicht ausdrücken, was der Code eigentlich macht, geht die Suche nach der optimalen Lösung weiter. Ein konsequentes Schema bei der Namensgebung – beispielsweise CamelCase oder Präfix – wird anhand der Programmiersprache gewählt.
In allen Programmiersprachen gibt es für Klassen, Funktionen und sonstige Details erlaubte und nicht erlaubte Namen. Um sich nachträgliche Arbeit durch Debuggen zu ersparen, sollten die Regeln vor der Code-Entwicklung bekannt sein. Abkürzungen fernab von bekannten Standardausdrücken erweisen sich als weniger gute Idee. Der nächste, der den Code bearbeitet, muss das Kürzel nicht kennen und steht nun vor einem Problem. Weiter spielt die richtige Namenslänge eine bedeutende Rolle. Weder zu kurze noch zu lange Namen eignen sich. Während der Code bereits aussagt, wie er etwas tut, sollte der Name konkret ausdrücken, was der Code macht.
4 | Die Bedeutung von Community- und Sprachstandards
Java und PHP haben gute Codes in Form empfohlener Standards definiert. Das gilt natürlich auch für andere Programmiersprachen. Jeder Entwickler sollte die Standards und Empfehlungen in seinen genutzten Programmiersprachen kennen und sich bei der Erstellung von Codes daran halten. Ohne die Kenntnis zu den essenziellen Standards ist ein guter Code nicht möglich.
Durch die vielen verschiedenen Standards und Regeln offenbart sich, dass es nicht „den Einen“ Code Codex gibt. Einige Konventionen, beispielsweise der Verzicht auf ellenlange Kommentare, sind sprachenübergreifend gültig. In anderen Standards zeigen sich deutliche Unterschiede im Regelwerk. Weder die Missachtung, noch die lineare Befolgung bekannter Standards erweisen sich in der Praxis als richtige Lösung. Man kann davon ausgehen, dass andere Entwickler die Konventionen ebenfalls kennen und auf den ersten Blick sehen, ob man ihnen mit dem präsentierten Code das Leben erschweren und unnötig Steine in den Weg legen möchte.
5 | Dokumentation – ja oder nein?
Die Grundthese besagt, dass gute Codes ohne lange Dokumentationen auskommen. Dennoch gehört die Dokumentation zum Code Codex und sollte daher nicht gänzlich ausgespart werden. Sinnvoll dokumentiert, wie dem agilen Manifest zu entnehmen ist, wird jeder Code einfach und verständlich lesbar. Für Entwickler, die mit einem Code viele Jahre lang arbeiten, kann eine gute Dokumentation hilfreich sein. Der User selbst sollte die Software allerdings ohne lange Erklärungen verstehen und nutzen können.
Eigene Konventionen, Namensstile und der Zugriff auf eigene APIs sind in die oben aufgeführten Empfehlungen eingeschlossen. Gute Dokumentationen vereinfachen die langfristige Arbeit und Wartung der Software, während zu viele oder gar nicht vorhandene Informationen zu Problemen führen. In einer guten Dokumentation sind auch wichtige – kurze und bündige – Kommentare innerhalb des Codes enthalten. Vor allem bei Informationen, was eine Funktion bewirkt, kann diese Methode praktisch sein. Die Erfassung des Gesamtbildes, auch der noch nicht gelösten Implementierungen, sollten dokumentiert und für einen schnellen Einstieg kurz erläutert werden.
Fazit
Jedes Entwicklerteam hat seinen eigenen Code Codex. Die Vermeidung von Bugs, die Begrenzung der Zeilenlänge und regelmäßige Reviews sind im Codex verankert. Um im Endeffekt einen hochqualitativen und guten Code zu erzeugen, sollte man sich auf das Vier-Augen-Prinzip berufen. Die fünf hier aufgeführten Tipps helfen dabei, schlechte Codes zu vermeiden und externen Teams die Arbeit mit der eigenen Entwicklung zu vereinfachen. Es ist ganz einfach – wenn es lesbar und verständlich ist.
Herzlichst
Ihre Algopioniere
erstellt von Julia Rosen in Zusammenarbeit mit unserem Team
Weitere Informationen über die 123 Invest Gruppe erhalten Sie unter www.1-2-3-invest.de
