Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:
Heute, am 1. Mai 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:
Anmut und Eleganz
So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:
Anmut und Eleganz – zwei Begriffe der Ästhetik und der Schönheit. Laut Wikipedia wird Anmut als
Form des Schönen, […] der unwillkürliche Ausdruck einer Harmonie
definiert, wohingegen Eleganz als
Ausdruck von besonderem Stil und Geschmack in Design, Architektur, […]
gilt und nicht nur ein ästhetisches Konzept, sondern gar ein entsprechendes Ideal darstellt.
Intuitiv werden diese Begriffe nicht zwingend mit Code assoziiert, doch spielen sie auch in der Entwicklung eine entscheidende Rolle: Je eher Code eine gewisse Anmut und Eleganz ausstrahlt, desto eher folgt seine innere Form wohlüberlegten Gedanken.
In anderen Worten: Code, an dessen innerer Form gefeilt wurde, ist nicht nur wart- und evolvierbarer als über die Zeit emergierter Code – er folgt zudem einer eigenen Ästhetik: Der des im mathematischen Sinne Eleganten.
Jeder Entwickler, der in seiner Ausbildung mit Mathematik in Berührung gekommen ist, kennt den Term einer schönen Beweisführung. Der Term schön bedeutet in diesem Kontext, dass der Beweis elegant geführt und kompakt ist wie auch auf überflüssige Haken und Wendungen verzichtet wird.
Dies klingt zunächst nach dem Konzept der minimalistischen Architektur: Ein Entwurf ist dann gelungen, wenn kein weiterer Bestandteil aus dem Gesamtbild entfernt werden kann, ohne dass die Qualität oder die Funktionalität des Entwurfs darunter leidet.
Insofern liegt die Vermutung nahe, dass anmutiger und eleganter Code gleichzusetzen sei mit minimalistischem Code: Dass Code so lange reduziert, Ausdrücke vereinfacht und zusammengefasst, und aufwändige Konstrukte durch kompakte ersetzt werden sollten, bis eine minimalistische Form erreicht ist, die ohne Qualitäts- oder funktionale Einbußen nicht weiter reduziert werden kann.
Gilt also die Gleichung anmutiger und eleganter Code gleich minimaler, kompakter und reduzierter Code?
Während dieses Ziel in der Mathematik durchaus in dieser Form gelten könnte, lässt es einen wesentlichen Aspekt von Code aus: Im Gegensatz zu einem mathematischen Beweis, der – einmal erfolgt – nur noch zu Referenzzwecken nachvollzogen wird, wird Code immer und immer wieder gelesen.
Die gängige Wendung
It was hard to write, so it should be hard to read.
ironisiert diesen Aspekt. Fakt ist, dass Code im Idealfall nur ein Mal geschrieben, aber potenziell unzählige Male gelesen wird – nicht nur von anderen Entwicklern, auch vom ursprünglichen Autor: In der Regel gilt dies spätestens dann, wenn Code auf Grund neuer oder geänderter Anforderungen entweder erweitert oder zumindest angepasst werden muss.
Code sollte also für den Leser leicht verständlich sein. Hierzu trägt zunächst die äußere, optische Form von Code einen essenziellen Teil bei. Entsprechende Fragen lauten beispielsweise:
- Tragen Bezeichner verständliche und beschreibende Namen, die semantisch zum Inhalt passen?
- Erläutern Kommentare, aus welchen Gründen der kommentierte Code auf diese Art und nicht anders entwickelt wurde?
- Hielt der Entwickler formale Kriterien wie Verwendung von Elementen wie Einrückung und Leerzeilen ein?
- Folgen so wohl Code wie auch Kommentare und Dokumentation der gültigen Rechtschreibung und Grammatik?
Doch neben dieser äußeren Form spielt auch die innere Form für die Verständlichkeit eine bedeutende Rolle. Die entscheidende Frage hierzu lautet, ob dem jeweiligen Zweck angemessene Sprachkonstrukte angewandt wurden. Ausgewählte Beispiele dafür bieten folgende Aspekte:
- Werden LINQ-Abfragen an Stelle von aufwändigen Schleifen mit zahlreichen, unter Umständen verschachtelten if-Anweisungen genutzt?
- Wie werden Schnittstellen, abstrakte Basisklasse und konkrete Klassen miteinander kombiniert?
- Werden Konstrukte wie beispielsweise das yield-Schlüsselwort dort eingesetzt, wo sie sinnvoll sind und Arbeit ersparen können?
Um diese Sprachkonstrukte angemessen einsetzen zu können, ist es erforderlich, sein Werkzeug zu beherrschen – sprich, die dargebotenen Mittel der persönlich gewählten Programmiersprache nicht nur zu kennen, sondern sie zu beherrschen.
Zur Verbesserung der inneren Form gibt es zahlreiche Regeln – bereits Werkzeuge zur statischen Codeanalyse wie FxCop oder die in Visual Studio integrierte Codeanalyse können hierbei eine wesentliche Hilfestellung leisten.
Je länger man sich jedoch als Entwickler mit diesen Themen beschäftigt und versucht, während der Entwicklung bewusst so wohl auf die innere wie auch auf die äußere Form von Code zu achten, desto eher stellt sich – auf Basis der nach und nach verinnerlichten Regeln – ein Gespür für ebenjene Anmut und Eleganz ein, die wart- und evolvierbaren Code auszeichnet.
Da dieses Gespür für ästhetisch gelungenen Code von handfesten Regeln getragen wird, besteht keine Gefahr, Initiativen wie beispielsweise Clean Code Developer zuwider zu handeln: Im Gegenteil – da dem Gespür für Ästhetik und Eleganz die Internisierung der Regeln zu Grunde liegt, erleichtert es letztlich den Umgang mit ebendiesen.
Eine Anmerkung in eigener Sache: Dieser Beitrag ist der – inzwischen achtzehnte – Kommentar im Rahmen von Noch Fragen, Bucher? Ja, Roden!. Unsere Reihe geht nun vorerst in eine Kreativpause, in der wir am Konzept und neuen Themen feilen werden. Auf absehbare Zeit werden wir diese Reihe fortsetzen.