Schöner Coden – Teil 4

Experten-Check: Was ist „schöner Code“ für Web-Experten?

Redaktion JAXenter

Es gibt so viel schönen Code! Aber leider auch sehr viel weniger schönen. Im vierten Teil unserer „Schöner Code“-Reihe haben wir die drei Web-Experten Niko Köbler, Karsten Sitterberg und Oliver Zeigermann nach ihrer Meinung gefragt. Für Sie ist schöner Code lesbar und entsteht durch Code Reviews. Denn man lernt niemals aus auf dem Weg zum schönen Code.

Die Web-Experten

Niko Köbler

Niko Köbler ist freiberuflicher Softwarearchitekt, Developer und Trainer für Java- und JavaScript-(Enterprise-)Lösungen, Integrationen und Web-Development.

karsten_sitterberg

Karsten Sitterberg ist als freiberuflicher Entwickler, Trainer und Berater für Java und Webtechnologien tätig. Karsten ist Physiker (MSc) und Oracle-zertifizierter Java Developer. Seit 2012 arbeitet er mit trion zusammen.

zeigermann_oliver

Oliver Zeigermann ist Entwickler, Architekt, Berater und Coach bei embarc in Hamburg. Oliver wendet seine Erfahrungen aus dem Java-Umfeld auch auf die Softwareentwicklung und Architektur mit JavaScript an.

Was hilft dir (technisch) beim schöner Coden? Welche Tools/Frameworks machen Code schön?

Niko Köbler: Zunächst müssen wir erst mal definieren, was „schön“ denn überhaupt bedeutet. Schönheit liegt bekanntlich ja im Auge des Betrachters. Mit „schön“ würde ich jetzt erst mal eine äußere Form assoziieren, die Code gut lesbar und erkennbar macht, also die Code-Formatierung. Dafür sollten in jedem Projekt und in jedem Team Regeln aufgestellt werden, wie man den Code formatieren möchte. Klammern auf die gleiche oder in die nächste Zeile, Leerzeilen, Namenskonventionen, etc. Ein Wildwuchs aus verschiedenen Stilen macht den Code auch sehr unschön. Hat man die Regeln ein Mal definiert, helfen moderne IDEs und Editoren, diese Regeln auch anzuwenden – entweder automatisiert oder manuell. Checks können während des Builds überprüfen, ob die Regeln auch eingehalten wurden. Dennoch sollte man beachten, dass Tools nur Dinge sind, die nicht mitdenken können. Das müssen wir bitte noch selbst tun!

Gegenseitige Code Reviews und Designdiskussionen nutzen allen Beteiligten.

Karsten Sitterberg: Für syntaktisch und ästhetisch schönen Code sind IDEs wie NetBeans oder WebStorm mit ihrem Autoformat- und Code-Completion Features sicherlich sehr hilfreich. Weiterhin bringt der Einsatz von Lintern bzw. statischer Codeanalyse eine Menge. Im Web-Umfeld werden zum Beisiel TSLint für TypeScript und JSHint für JavaScript verwendet. Generell finde ich Mitarbeit bei Open-Source-Projekten gut – nicht nur in Sachen Codestyle. Gegenseitige Code Reviews und Designdiskussionen nutzen allen Beteiligten.

Oliver Zeigermann: Ich finde es erst einmal wirklich schwierig zu sagen, was guten Code überhaupt ausmacht. Dies kann höchst subjektiv und auch Abhängig vom Kontext sein. Schon oft habe ich Code, den ich nur schwer verständlich und unschön fand, umgebaut und fand ihn danach klarer und einfacher. Es ist dann aber nicht mehr möglich zu sagen, ob es nun daran liegt, dass ich mich lange mit dem Code und dem Problem beschäftigt habe und ich den Code daher klarer finde. Wie würde ich ihn nach einem Monat finden? Dazu kommt: Je nach Entwickler und Stil kann ein und derselbe Code klar und schön oder sonderbar, über-designed oder hässlich wirken. Daher ist es wichtig, dass ein Team für sich entscheidet, was es für guten und schönen Code hält. Mein Werkzeug wäre daher das Code Review im Team.

Bei welchem Fehler rollen sich bei dir die Fußnägel hoch? Was ist schlechter Code?

Niko Köbler: Schlechter und unschöner Code, der vor allem auf Unwissenheit und fehlende Detailkenntnis des Entwicklers zurückzuführen ist, ärgert mich immer wieder. Gerade in der JavaScript-Entwicklung scheinen immer noch einige Entwickler der Meinung zu sein, die Weisheit mit dem Löffel gegessen zu haben und sich nicht mit den Details auseinandersetzen zu müssen. „Undefined“ ist in JavaScript halt immer noch was anderes als „null“. Wenn man dann mit der falschen Methode auf den falschen Wert überprüft, kann es zu sehr ärgerlichen Laufzeitfehlern kommen.

In vielen großen Unternehmen treffe ich immer noch auf Entwickler, die nach der sogenannten Hungarian Notation programmieren. Diese Schreibweise erhöht die Lesbarkeit in keinster Weise, ganz im Gegenteil. Unsere IDEs sind heutzutage gut genug, um diese Informationen auf anderem Wege zu transportieren bzw. zu visualisieren.

Auch nicht schön, wenn ein Entwickler schreibfaul ist, wie in diesem realen(!) Beispiel:

ResultSet rs = stmt.executeQuery("...");
String s1 = rs.getString(0);
String s2 = rs.getString(1);
int i = rs.getInt(2);
// usw...

Was macht er hier? Was will er bezwecken? Ohne das SQL-Statement zu analysieren, kann hier keine Aussage über die fachliche Intention getroffen werden. Ein paar mehr Zeichen hätten dem Kollegen hier sicherlich kein Abbruch getan und allen anderen Beteiligten sehr geholfen.

Karsten Sitterberg: Vor allem, wenn absolutes Unverständnis an den Tag gelegt oder schlicht nicht nachgedacht wird,  bei dem was man tut. Beispiel:

//...
else document.write("Your Browser doesn't support JavaScript");
//...

Was man immer im Hinterkopf behalten sollte ist jedoch, dass schlechter Code immer eher ein Symptom ist. Nämlich für mangelndes Verständnis für die Aufgabenstellung, unsauberes bzw. schlechtes Design von Software oder zu geringes Investment in Architektur. Guter Code ist lesbar und es ist sofort ersichtlich, was er tun soll und ob er es auch tut. Ein (satirisch gemeintes) Negativbeispiel ist die FizzBuzzEnterpriseEdition.

Oliver Zeigermann: Außerhalb jedes Kontexts ist es wirklich schwer von schlechtem Code zu sprechen. Abstrakt gesagt ist schlechter Code der, der Dinge zu kompliziert macht oder unklar ist. Konkret habe ich eine Menge schlechten Code geschrieben, da ich ihn schon einige Zeit – teilweise nur einen Tag, manchmal einige Jahre – später nicht mehr verstanden habe. Eine tiefe Verschachtelung, Schleifen und Abfragen sind oft schwer zu verstehen. Das kann daran liegen, dass das Problem komplex ist. Dann werden auch andere Lösungen nicht zwingend einfacher zu verstehen sein. Manchmal liegt es aber auch einfach nur daran, dass man selbst das Problem nicht vollständig durchdrungen hat und der Code daher komplexer ist als notwendig. Wirklich schlechter Code entsteht aber oft dann, wenn man nicht das aktuelle Problem, sondern ein komplexeres Problem löst, einfach weil es spannender ist als das aktuelle.

Wenn du eine Eigenschaft nennen müsstest, die für dich schönen Code ausmacht, welche wäre das und warum?

Niko Köbler: Schöner Code muss für mich vor allem schnell les- und erkennbar sein. Also gut strukturiert in logische Blöcke, die nicht aus zu vielen Zeilen bestehen, sehr gerne auch immer mal wieder eine Leerzeile zwischendurch, aber nicht nach jeder Operation. Dann wird’s nämlich wieder unübersichtlich. Methoden, Funktionen und Variablen sollten sprechende Namen haben, damit man schnell weiß, was gemeint ist und was die Funktion macht. Wir müssen uns beim Code-Schreiben immer wieder bewusst machen, dass der Code, den wir schreiben, von anderen Entwicklern gelesen und verstanden werden muss. Was bringt es also, wenn ich mich in meinen eigenen Konventionen sehr gut zurechtfinde, mein Kollege ein Schreibtisch weiter aber nicht versteht, was ich ausdrücken möchte? Jeder Entwickler sollte sich dieses Zitat von John F. Wood groß ausdrucken und neben den Monitor hängen:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

Karsten Sitterberg: Schöner Code definiert sich bei mir vor allem über seine Klarheit: Kann man den Code durchlesen und dabei direkt verstehen, was dieser tut? Schöner Code sollte wenig Dokumentation enthalten als vielmehr selbst dokumentierend sein. Dies ist im allgemeinen Code, der zunächst designet und erst dann geschrieben wurde. In der Designphase sollte auch die Nutzung von vorhandenen Funktionen der Standardbibliothek und verfügbaren Libraries untersucht werden, bevor man das Rad in eckig neu erfindet. Anders als in obigem Enterprise FizzBuzz.

Oliver Zeigermann: Schöner Code erfüllt die Anforderungen, die an ihn gestellt werden. So gut wie eben möglich. Das kann Wartbarkeit sein oder Verständlichkeit, Effizienz, Sicherheit, Lesbarkeit für einen bestimmten Typ Entwickler. Typischerweise eine Mischung von vielen Anforderungen. Häufig sind hier nur Kompromisse möglich. Ein Beispiel: Vor mehr als 15 Jahren habe ich einmal Code in einer einzigen Funktion über mehrere Bildschirmseiten mit vielen Abfragen und Schleifen hintereinander und ineinander geschrieben, der keine Unterfunktionen und nur eine Untermenge von Spracheigenschaften nutzte. Diesen Code halte ich auch nach 15 Jahren für einen der besten und schönsten Codes, die ich jemals geschrieben habe. Dies wird jedoch nur klar, wenn man die Anforderungen an diesen Code kennt (Könnt ihr euch vorstellen, welche das gewesen sein mögen?). Jede Clean-Code-Fibel hätte diesen Code aber in der Luft zerrissen. Man kann Code also häufig nicht für sich, sondern nur im Kontext bewerten.

shutterstock_107815670Schöner Coden
In unserer Reihe zum Thema „Schöner Coden“ stellen wir Experten verschiedener Disziplinen die Frage: Was ist eigentlich schöner Code? Welche Eigenschaft hat schöner Code aus der Sicht eines Software-Architekten? Und wie blicken Tester auf dieses Thema? Hier finden Sie eine Übersicht der bisher veröffentlichten Experten-Checks:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Experten-Check: Was ist „schöner Code“ für Web-Experten?"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Norkos
Gast

Mich wundert dass so wenig auf Literatur eingegangen wird.
Ein Standard-Werk dass jeder Entwickler mal gelesen haben sollte, ist meiner Meinung nach „Clean Code“ von Robert Cecil Martin.

Neben den Basics (Sprechende Bezeichner, Kurze Methoden, usw.) gehört für mich auch dazu dass der Code Testbar ist. Auch eine Trennung von Abstraktionsebenen kann Code wesentlich verständlicher Machen.

Wichtig ist eigentlich nur der eigene Ehrgeiz besser zu werden – leider ist dieser nicht selbstverständlich.

Melanie Feldmann
Mitglied

Hallo Norkos,

nach Lesetipps zum Thema „Schöner Coden“ haben wir unsere Experten natürlich auch gefragt. Ein Post mit den geballten Empfehlungen kommt noch diese Woche.