Desktop-Klick-Geste unter macOS deaktivieren

Seit der aktuellen macOS-Version 14.0 (Sonoma) existiert eine Klick-Geste für den Desktop. Sobald auf diesen geklickt wird, werden alle Fenster aus dem Weg geräumt. Ziel ist es den Desktop zu sehen, was wahrscheinlich vor allem für die Widgets, welche nun auch dort platziert werden, geschehen ist.

Die Einstellungen unter macOS 14

Um dieses Verhalten abzustellen, müssen die Einstellungen geöffnet werden. Dort findet sich unter dem Punkt Schreibtisch & Dock, die Einstellung Zum Anzeigen des Schreibtischs auf Hintergrund klicken. Diese sollte auf den Wert Nur in Stage Manager gestellt werden. Anschließend kann der Desktop wieder ohne Probleme angeklickt werden.

State of Matter

Der Smarthome-Standard Matter ist gekommen, um den Markt aufzurollen. Doch wie sieht es mit der Umsetzung aus und kann der Standard seinem Versprechen gerecht werden?

Nachdem der Standard, knapp drei Jahre in der Entwicklung war, wurde er schlussendlich im November 2022 offiziell auf einem Launch-Event in Amsterdam vorgestellt.

Bereits damals kündigten viele Hersteller ihre Unterstützung an. In der sich für den Matter-Standard zuständig zeichnenden Connectivity Standards Alliance (CSA), finden sich über 500 Firmen, die unter dem Dach der Organisation vereint sind.

Darunter sind klingende Namen, wie Amazon, Apple, Google, Nordic Semiconductor, NXP Semiconductors, Samsung, Silicon Labs und viele mehr. Doch wie sieht es aus mit der Unterstützung des Standards?

Android und iOS

Matter unterstützt sogenannte Multi-Admin-Funktionalität. Dies bedeutet, dass eine Matter-Installation von unterschiedlichsten Geräten gesteuert werden kann. Für diese Steuerung wurde in unterschiedlichste Betriebssysteme mittlerweile entsprechende Unterstützung eingebaut. Diese wird meist im Rahmen der jeweiligen Smarthome-Strategie der Hersteller ausgestaltet.

So ist die Matter-Unterstützung unter iOS in die Home-App integriert. Eingeführt wurde diese Unterstützung mit der Version 16.1 von iOS. Mit diesen Updates im Oktober 2022, wurden auch andere Systeme wie watchOS mit einer Matter-Unterstützung versehen.

Unter Android wurde die Unterstützung für Matter ab Version 8.1 eingeführt, sofern die Play-Dienste ab Version 22.48.14 installiert sind. Auch hier kann das Smarthome unter Nutzung des Matter-Standards über die Home-App genutzt werden.

Smarthome-Ökosysteme

Interessant ist auch die Unterstützung der jeweiligen Home-App von Google und Apple auf dem Konkurrenzsystem. So sind die Home-Apps von Apple und Google auch auf Android respektive iOS verfügbar und unterstützen dort ebenfalls den Matter-Standard.

Andere Ökosysteme für Smarthomes sind mittlerweile ebenfalls auf den Matter-Standard angepasst. So unterstützt SmartThings von Samsung seit einiger Zeit Matter unter iOS und Android. Allerdings ist diese Unterstützung nicht komplett. So werden unter anderem Bridges, welche im Matter-Standard vorgesehen sind, durch die App noch nicht unterstützt.

Bridges dienen zur Anbindung von nicht direkt kompatiblen Systemen, an ein Matter kompatibles System. Ein solche definiert sich im Standard dadurch, dass sie ein Matter-Knoten darstellt, welcher ein oder mehrere Nicht-Matter-Geräte darstellt.

Die Alexa-App unterstützt, analog zu den anderen Systemen, seit einiger Zeit den Matter-Standard. Dies ging einher mit der Aktualisierung vieler Alexa-Echo-Geräte, insbesondere in den neuen Generationen der Gerätereihe. Mit Home Assistant verfügen Open Source-Lösungen mittlerweile auch über Unterstützung für Matter.

Border-Router und Controller

Bei Matter wird für die Kommunikation der Geräte untereinander Wi-Fi, Ethernet oder Thread benutzt; für die Kommissionierung Bluetooth LE. Näheres dazu findet sich im entsprechenden Hintergrundartikel.

Ein komplexes Matter-Netzwerk

Thread versteht sich als selbstheilendes Mesh-Netzwerk. Es ist darauf ausgelegt, Geräte miteinander zu verbinden, welche eine geringe Datenrate benötigen und möglichst wenig Energie verbrauchen sollen. Das Protokoll besticht durch sein simples Design und ermöglicht niedrige Latenzen.

Basierend auf IPv6 wird somit bei Matter ein Netz gebildet, über welches die unterschiedlichen Geräte miteinander kommunizieren. Zur Anbindung eines Thread-Netzwerks an das Matter-Ökosystem werden Border-Router benötigt, welche die Verbindung zum hauseigenen LAN herstellt.

In vielen Haushalten müssen diese allerdings nicht extra angeschafft werden, da bestehende Geräte, wie einige Smart-Speaker von Amazon, per Update zu solchen Border-Routern aktualisiert werden konnten.

Hintergrund hierfür ist, dass Thread auf IEEE 802.15.4 aufsetzt, bei welchem es sich um einen Standard für kabellose Netzwerke mit geringen Datenraten handelt. In IEEE 802.15.4 ist die Bitübertragungsschicht (Physical Layer) und die Data-Link-Schicht definiert.

Neben Thread setzt unter anderem auch ZigBee, ebenfalls ein Mesh-Protokoll, auf IEEE 802.15.4 auf, was eine Aktualisierung solcher Geräte, hin zu Thread, perspektivisch möglich macht. Damit sind viele Funkchips welche ZigBee unterstützen in der Theorie für Thread geeignet.

Apple hat die Unterstützung für Matter mit der HomePod-Version 16.1 implementiert. Auch der Apple TV kann in bestimmten Generationen als Border-Router verwendet werden. Aktuell werden der Apple TV 4K in der zweiten und dritten Generation neben dem HomePod Mini und dem HomePod in der zweiten Generation unterstützt.

Bei Amazon wurde mittlerweile eine kleine Armada an Geräten mit einer Matter-Unterstützung ausgestattet. So unterstützt der Echo der vierten Generation die Thread-Funktechnik und kann als Border-Router verwendet werden. Daneben können die Geräte Echo, Echo Plus und die Echo Dot-Serie als Matter-Controller verwendet werden. Hier wird gewöhnlich ab der zweiten und dritten Generation der Geräte eine Unterstützung geliefert.

Die eero-Router, hergestellt von einer Tochterfirma von Amazon, können als Border-Router genutzt werden. Hier findet sich eine entsprechende Unterstützung in den Modellen eero 6, eero 6+, eero Pro, eero Pro 6E und eero Pro 6.

Google verfügt über eine Reihe von Geräten, welche mittlerweile Matter unterstützen und als Border-Router genutzt werden können. So werden die Smart-Speaker Google Home, Google Home Mini, Nest Mini, Nest Audio und die Displays Nest Hub (1. Generation), Nest Hub (2. Generation) und der Nest Hub Max unterstützt. Auch der Nest Wifi Pro (Wi-Fi 6E) Router verfügt über eine entsprechende Unterstützung.

Neben den Geräten von Big Tech, finden sich in vielen Haushalten, Router der Firma AVM, namentlich die FRITZ!Box. Die neuen Modelle 5690 XGS & 5690 Pro, welche noch in diesem Jahr erscheinen sollen, verfügen neben dem von AVM bevorzugten DECT ULE auch über Unterstützung für ZigBee. Basierend auf dieser Möglichkeit, soll eine spätere Matter-Unterstützung Einzug halten. Das FRITZ!Smart Gateway soll in Zukunft ebenfalls Unterstützung für Matter erhalten.

Daneben finden sich einige andere Hersteller, welche mittlerweile entsprechende Unterstützung bzw. Border-Router liefern, namentlich der Aeotec Smart Home Hub, einige Geräte der Nanoleaf-Produktpalette und der Samsung SmartThings Hub in Version 3.

Bei anderen Geräten, wie dem Dirigera-Hub von Ikea, fehlt eine angekündigte Unterstützung immer noch.

Hardware

Doch wie sieht es bei den Herstellern der eigentlichen Smarthome-Geräte aus? Erst durch sie wird das Smarthome steuer- und erfahrbar. Neben den Konzernen Apple, Amazon und Google, welche sich in vielen Fällen mit entsprechender Software-Unterstützung und dem Bau von Border-Routern und Controllern beschäftigen, existieren auch die Firmen, welche Sensoren und Aktoren liefern.

In diesem Feld sind unter anderem Aeotec, Eve Systems, Signify und einige andere Anbieter unterwegs. Dagegen haben Hersteller, wie Belkin, ihre Unterstützung für Matter mittlerweile zurückgezogen.

Ein Sensor von Fibaro

Firmen wie Fibaro, haben sich trotz einer großen Auswahl an Smarthome-Produkten bisher nicht zu Matter geäußert. Doch wie sieht es bei den Herstellern im Einzelnen aus?

Aeotec

Aeotec, hervorgegangen aus den Aeon Labs, ist mittlerweile eine Firma mit Hauptsitz in Hamburg. Bekannt geworden ist die Firma primär durch Smarthome-Geräte, welche den Z-Wave-Standard unterstützten.

Mit dem Aeotec Smart Home Hub liefert Aeotec einen zu Matter und dem Thread-Funkstandard kompatiblen Hub. Der ZigBee-Stick, mit dem Namen Zi-Stick, soll in Zukunft, per Update, auch das Thread-Protokoll unterstützen.

Ansonsten setzen die Aktoren und Sensoren von Aeotec nicht auf Matter, sondern auf das Z-Wave-Protokoll und die entsprechende Funktechnik auf.

Eltako

Im professionellen Bereich bietet die Firma Eltako mittlerweile Matter zertifizierte Geräte an. Hier handelt es sich unter anderem um Beschattungsaktoren, ein Stromstoß-Schaltrelais und Dimmaktoren.

Damit ist es möglich, bestehende Installationen über Matter einzubinden. Neben der Matter-Integration verfügen sie unter anderem über eine REST-API, sowie eine Apple Home-Integration.

Eve Systems

Eve Systems, früher als Elgato Systems bekannt, bietet Smarthome-Geräte für unterschiedlichste Bereiche an. Mittlerweile werden von der Firma auch erste Matter-Geräte angeboten.

Der Bewegungssensor Eve Motion

Darunter fallen die schaltbare Steckdose Eve Energy, die Kontaktsenoren Eve Door & Window und der Bewegungssensor Eve Motion. Teilweise agieren die Geräte als Matter-Controller sowie als Border-Router für das Thread-Protokoll.

Die Produkte Eve Shutter Switch und Eve Flare unterstützen bereits das Thread-Protokoll und sollen mit einem späteren Update, entsprechende Matter-Unterstützung erhalten. Das Gleiche soll auch für die Produkte Eve MotionBlinds, Eve Thermo, Eve Light Switch, Eve Weather und Eve Room gelten. Für diese Geräte war eine entsprechende Unterstützung bis Ende 2022 angekündigt, wurde allerdings bisher noch nicht ausgeliefert.

Govee

Govee ist seit 2017 im Smarthome-Bereich tätig und hat unterschiedlichste Produkte wie LED-Streifen und Sensoren im Angebot. Bekannt geworden sind sie auch durch eine kurzzeitige Auslistung bei Amazon, was wohl auf das Verpackungsdesign einiger Produkte zurückzuführen war. Diese besaßen eine auffällige Ähnlichkeit mit den Philips Hue-Produkten von Signify.

Mit dem Govee RGBIC LED Strip M1 hat Govee mittlerweile sein erstes Matter fähiges Produkt auf den Markt gebracht.

Leviton

Der nordamerikanische Hersteller Leviton, ist in Europa, aufgrund seines Zuschnitts auf den amerikanischen Markt, eher weniger bekannt. Dafür liefert er in seiner Heimat entsprechende Hardware mit Matter-Unterstützung.

Zu dieser gehört ein Smart Switch, eine schaltbare Steckdose und einige Dimmer. Konkret sind dies die Geräte Smart Wi-Fi 2nd Gen D26HD Dimmer, D215S Switch, D215P Mini Plug-In Switch und der D23LP Mini Plug-In Dimmer, welche über ein entsprechendes Firmware-Update aktualisiert werden können.

Andere Geräte von Leviton, sollen in Zukunft per Update in den Genuss einer Matter-Unterstützung kommen.

Nanoleaf

Nanoleaf wurde 2012 gegründet und finanzierte erste Produkte über Kickstarter. Mittlerweile liefern sie eine Reihe von ausgefallenen Beleuchtungslösungen.

Nanoleaf stellt ungewöhnliche Beleuchtungslösungen her

Neue Produkte, wie der Essentials Matter Lightstrip und die Essentials Matter Smart Bulb, sind von Werk aus mit einer Matter-Unterstützung versehen und können in entsprechende Ökosysteme eingebunden werden.

Bestehende Produkte der Essentials-Reihe können nicht per Update auf den Matter-Standard gehoben werden, da dies seitens der Hardware nicht unterstützt wird. Ob die Produktreihen Elements, Lines und Shapes eine entsprechende Aktualisierung auf Matter erhalten ist zurzeit noch unklar. Angebunden werden diese Systeme per WLAN. Daneben arbeiten diese Geräte bereits heute als Thread-Border-Router.

Signify

Das unter der Marke Philips vertriebene Lichtsystem Hue, ist bereits seit 2012 auf dem Markt. Entwickelt und vertrieben wird es von dem mittlerweile unabhängigen Unternehmen Signify, welches früher unter dem Namen Philips Lighting firmierte.

Das System, welches auf ZigBee basiert, ist so zumindest funktechnisch unter Umständen auf Thread aktualisierbar. Die Leuchtmittel sollen allerdings nach Aussage von George Yianni, seines Zeichens Head of Technology Philips Hue bei Signify nicht auf Thread aktualisiert werden.

Hier wird seitens Signify die Strategie gefahren, nur den Hue Hub mit einer Matter-Unterstützung zu versehen. In der FAQ wird dies wie folgt beschrieben:

Alle Philips Hue Lampen und intelligentes Zubehör wie der Hue Dimmschalter und Hue Smart Button funktionieren mit Matter, wenn sie über die Philips Hue Bridge verbunden sind. Die einzigen Ausnahmen sind die Philips Hue Play HDMI-Sync Box und der Tap Dial Switch.

Auch dieses Update lässt allerdings noch auf sich warten, bzw. findet sich in einer Beta-Version, welche für Entwickler freigegeben wurde.

Der Hintergrund für diese Herangehensweise ist, dass die Hue-Bridge nicht nur als einfache Verbindung zwischen dem WLAN und den angeschlossenen ZigBee-Geräten gesehen wird, sondern als Zentrale für Abläufe und Automatisierungen.

Solche Funktionalitäten sollen nicht direkt in die Leuchtmittel eingebaut werden. Es wird befürchtet, damit die Komplexität des Systems zu erhöhen. Auch die Entscheidung, die Geräte mittelfristig nicht auf Thread umzurüsten, wird entsprechend begründet. Hier wird argumentiert, dass das entsprechende Mesh-Netzwerk über ZigBee im Laufe der Jahre produktionsreif gemacht wurde. Bei Thread steht die Befürchtung im Raum, dass hier noch viele Kinderkrankheiten und Inkompatibilitäten zu beheben sind, bis ein vergleichbarer Stand, wie mit der aktuellen Implementierung erreicht werden kann.

Mittlerweile ebenfalls zu Signify gehörend ist das ehemalige Start-up Wiz, welches auch Beleuchtungslösungen anbietet. Diese werden per WLAN angebunden und arbeiten ohne Bridge.

Bei Wiz wird Matter bei Leuchtmitteln und Smart Plugs, welche ab dem zweiten Quartal 2021 produziert worden sind, unterstützt. Die entsprechenden Updates für die meisten Bestandsgeräte sind hierbei mittlerweile erschienen.

SwitchBot

Die 2016 gegründete Firma befasst sich mit der Entwicklung von Smarthome-Geräten, wie Schlössern, Kameras und Schaltern.

Mit dem SwitchBot Hub 2 brachte sie ihr erstes Matter fähiges Produkt auf den Markt. Über diesen können andere Geräte wie SwitchBot Curtain ebenfalls per Matter angebunden werden.

Weitere Produkte sollen folgen, sind aber im Moment noch in Entwicklung. Hier sind Erscheinungstermine für das dritte und vierte Quartal 2023 anvisiert.

TP-Link

Neben Netzwerkprodukten bietet der chinesische Hersteller TP-Link mittlerweile auch eine Palette von Smarthome-Produkten an. Diese firmieren unter den Marken bzw. Unternehmen Tapo und Kasa.

Anfang des Jahres wurde mit dem Tapo P125M, einer schaltbaren Steckdose, ein Matter fähiges Produkt aus dieser Produktreihe vorgestellt.

In Zukunft sollen Matter-Updates für weitere Steckdosen, Schalter, Leuchtmittel und Thermostate erscheinen.

Tridonic

Tridonic, eine zur Zumtobel Group gehörende Firma, ist vorwiegend im professionellen Bereich bekannt. Auch hier wird an Matter-Lösungen gearbeitet, bzw. solche werden angeboten.

Die Matter-Produkte von Tridonic

Hierbei werden ein Wireless Matter Treiber, mit 24 V Konstantspannung, erhältlich in 35 W, 60 W, 100 W, 150 W, sowie ein Wireless Matter to DALI Passivmodul und ein Wireless Matter to DALI SR Modul angeboten. Über die Wireless-Module können bestehende Systeme nachgerüstet und somit Beleuchtungen Matter fähig gemacht werden.

Angebunden sind die Module per Thread. Für diese Module wurden Updates angekündigt, welche unter anderem die Änderung der Farbtemperatur möglich machen sollen, sobald dies vom Matter-Standard unterstützt wird.

Xiaomi

Unter der Marke bzw. der Tochterfirma Aqara bietet Xiaomi mittlerweile ebenfalls Matter kompatible Geräte an.

So unterstützt der Hub M2, ab der Firmware Version 4.0.0 Matter in einer Betaversion. Dabei dient dieser dann auch als Bridge, für Nicht-Matter-Geräte, wie die angeschlossenen ZigBee-Geräte. Das Update dient der Einbindung des Hubs in Matter-Umgebungen, ändert allerdings nichts am verwendeten Funkstandard im Hub selbst. Auch der Hub M1S wurde mittlerweile mit einem entsprechenden Update versehen, welches die Matter-Unterstützung im Beta-Stadium nachrüstet.

Neben diesen Hubs existieren im Portfolio von Aqara einige andere Hubs, wie der Hub E1 oder die Camera Hub-Serie. Auch diese sollen perspektivisch Updates für Matter erhalten. Angekündigt waren diese Updates für den Lauf des Jahres 2023.

Allterco

Während die Firma Allterco den wenigsten ein Begriff ist, sieht es bei der Marke Shelly anders aus. Unter dieser werden günstige Smarthome-Komponenten wie schaltbare Steckdosen, Unterputzschalter, Sensoren und einige andere Produkte angeboten.

Der Shelly Plug S

Angesteuert werden die Geräte meist per WLAN oder Bluetooth. Für die Produkte der Plus- und Pro-Reihe wurde Unterstützung für Matter für das zweite Quartal 2023 angekündigt. Allerdings wurde die Veröffentlichung zu diesem Zeitpunkt wieder abgesagt und auf die Zukunft verschoben. Damit ist unklar, wann mit ersten Matter-Geräten unter der Marke Shelly zu rechnen ist.

Bosch

Die Firma Bosch mischt beim Smarthome mit dem System Bosch Smart Home mit. Anfang des Jahres wurde angekündigt, dass das System kompatibel mit dem Matter-Standard sein wird.

So wurde mitgeteilt, dass unter anderem der Smart Home Controller II Matter unterstützen wird. Aktuell wird allerdings nur beschrieben, dass die Geräte auf den Standard vorbereitet sind. Ein kostenloses Update soll später folgen.

Ikea

Der schwedische Möbelproduzent wollte mit dem Dirigera einen Hub mit Matter-Unterstützung auf den Markt bringen. Während der Hub seit Ende 2022 erworben werden kann, sieht es mit dem entsprechenden Update bisher weniger erfreulich aus.

Dieses sollte im ersten Halbjahr des Jahres 2023 erscheinen. Andere Smarthome-Geräte aus dem IKEA-Bestand unterstützen gegenwärtig kein Matter. Auch entsprechende Ankündigungen sind bisher nicht erfolgt.

Da die IKEA Produkte auf ZigBee aufsetzen, wäre, wenn die entsprechenden Funkcontroller dies zulassen, ein Update auf Thread im Rahmen der Matter-Unterstützung denkbar.

Nuki

Die Firma Nuki ist vorwiegend für ihre Türschlösser bekannt. Die Kommunikation der Schlösser läuft über das Bluetooth Low Energy-Protokoll, welche auch über die Nuki Bridge eingebunden werden können und damit indirekt per WLAN ansteuerbar sind.

Eines der Smart Locks von Nuki

Auch wenn die Firma bisher keine Matter-Produkte anbietet, wurde bereits an ersten Prototypen gearbeitet. Eine Aktualisierung bestehender Produkte auf den Matter Standard ist hierbei nicht geplant.

Schneider Electric

Der französische Konzern Schneider Electric hat seine Pläne für Matter mittlerweile verkündet. So sollen die neuste Generation der Wiser Gateways mit Matter kompatibel sein. Dieses dient als Bridge für die angeschlossenen ZigBee-Geräte. Auch die Wiser Home-App soll in Zukunft mit einer entsprechenden Unterstützung versehen werden.

Die ersten Produkte, welche Matter unterstützen sollten, sind das Wiser Gateway und der Wiser Smart Plug. Allerdings ist dies bisher aus den Spezifikationen der Produkte nicht ersichtlich.

Shortcut Labs

Shortcut Labs, eine schwedische Firma, entwickelt und vertreibt mit Flic einen smarten Bluetooth-Taster und dem Flic Hub eine zentrale Steuerungsmöglichkeit für Smarthome-Geräte.

Zur Matter-Unterstützung hat sich Shortcut Labs vor etlichen Monaten geäußert. Diese ist für das Jahr 2023 anvisiert und soll sich auf sämtliche Produkte der Hub-Serie erstrecken. Bisher sind allerdings noch keinerlei Updates für diese Produkte verfügbar.

Weitere Hersteller

Neben den besprochenen Hersteller existieren noch andere Hersteller, welche das eine oder andere Matter fähige Produkt in ihrem Portfolio haben oder solche angekündigt haben. Zu diesen gehören unter anderem Mediola, Netatmo, Sonnof und Ubisys.

Interessant ist auch die angekündigte Unterstützung von Smart-TVs der Hersteller LG und Samsung. Diese sollen in Zukunft über Matter-Unterstützung verfügen und sich so zur Steuerung von Matter-Geräten eignen.

Fazit

Nach einigen Startschwierigkeiten, finden sich nun die ersten Hersteller, welche fertige Produkte für den neuen Standard ausliefern.

Allerdings scheint es auch, dass viele Hersteller die Komplexität von Matter unterschätzt haben und hier auf einen späteren Einstieg in den Markt hinarbeiten. Hier hat Matter bis zu einer entsprechenden Durchdringung des Marktes noch einiges vor sich.

Gemeinsam haben die Ankündigungen, dass sich die Matter-Unterstützung meist verspätet und gar ganz abgekündigt werden.

Ob hier die Komplexität, des doch recht umfangreichen Standards, unterschätzt wurde, darüber kann nur spekuliert werden. Daneben bedeutet eine Unterstützung für Matter nicht automatisch volle Kompatibilität. So wird auf den Echo-Geräten, in den ersten Iterationen, nur eine Handvoll Produktkategorien des Standards unterstützt. Namentlich sind dies Lampen, Schalter und Steckdosen.

Dies führt z. B. zu dem Problem, dass Matter-Bridges im Amazon-Kontext aktuell nicht genutzt werden können. Das Gleiche gilt für SmartThings von Samsung.

So fühlt sich der Matter-Start in vielen Fällen holprig an und kommt nur Stück für Stück voran. Es bleibt abzuwarten, ob hier in Zukunft, nachdem der Standard etabliert ist, Besserung kommt.

Die Einfachheit, welche dem Endbenutzer versprochen wurde, erstreckt sich leider nicht auf die Implementation seitens der Hersteller. Dies zeigt, wie herausfordernd es ist, einen neuen Standard in einem bereits etablierten Markt zu implementieren. Trotz der Versprechen von einfacher Handhabung und nahtloser Kompatibilität ist die Realität oft eine andere. Die Implementierung von Matter erfordert eine genaue Planung und sorgfältige Ausführung. Viele Hersteller scheinen sich noch in der Anfangsphase dieses Prozesses zu befinden.

Allerdings sollte berücksichtigt werden, dass diese anfänglichen Herausforderungen nicht unbedingt auf langfristige Probleme hindeuten. Sie könnten viel mehr als Wachstumsschmerzen betrachtet werden, die oft mit der Einführung neuer Technologien einhergehen.

Ein bedeutsamer Aspekt, der im Kontext von Smarthome-Installationen hervorgehoben werden sollte, ist die Langlebigkeit einer solchen. Sie ist nicht auf einen kurzen Zeitraum von wenigen Jahren ausgelegt, sondern soll teilweise Jahrzehnte genutzt werden. Hier muss der Matter-Standard sich ein entsprechendes Vertrauen erarbeiten und die Hersteller eine langfristige Unterstützung bereitstellen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Coding Conventions

Die Entwicklung von Software zeichnet sich in der heutigen Welt oft dadurch aus, dass sie unter Mitwirkung unterschiedlichster Entwickler bewerkstelligt wird. Im Rahmen einer solchen Entwicklung kommt es darauf an, bestimmte Standards und Best Practices einzuhalten.

Neben dem passenden Workflow kommen hier Coding Conventions zum Tragen und bilden einen wichtigen Baustein um Quelltext effizienter, lesbarer und zuverlässiger zu gestalten.

Was sind Coding Convention?

Eine Coding Convention definiert sich über bestimmte Stilregeln und Best Practices, bezogen auf eine Programmiersprache. Innerhalb der Konvention werden viele Aspekte der Programmiersprache und ihrer sprachlichen Elemente behandelt. Dies fängt bei Regeln zur Formatierung an, führt sich fort mit der Benamung von Variablen und anderen Strukturen und erstreckt sich auch auf andere Bereiche, wie Reihenfolgen und Zeilenlängen.

Warum werden sie benötigt?

Nun kann sich natürlich die Frage gestellt werden, warum eigentlich Coding Conventions benötigt werden?

Neben offensichtlichen Gründen, dass sie vielleicht eine Anforderung des Kunden sind, gibt es auch andere Gründe für diese Konventionen. So werden die meisten Projekte nicht von einer einzelnen Person betreut und für die Entwickler eines Produktes ist es einfacher, wenn der Quelltext nach identischen Standards entwickelt wurde. Dies ermöglicht eine schnellere Einarbeitung und hilft auch bei anderen Dingen, wie der Verminderung von Merge-Konflikten bei der Arbeit mit Versionskontrollsystemen.

Damit tragen diese Konventionen dazu bei, die Zusammenarbeit zwischen Entwicklern zu erleichtern, indem sie eine einheitliche und konsistente Basis schaffen.

Eine Welt ohne Coding Conventions

Natürlich können Programme auch ohne Coding Conventions geschrieben werden. Dies kann zu interessanten Programmen führen:

#include 

...

yeet Yeet Yeeet yeeeT 
Yeeeet
yEet yEEt yeEt yyeet yeett yeetT
yeeT yet yeetT
yeeeeT

Bei diesem Programm stellen sich bei der Betrachtung mehrere Fragen. In welcher Sprache ist es geschrieben? Ist es überhaupt lauffähig? Und was ist der eigentliche Zweck des Quelltextes?

In diesem Beispiel wurde das C-Programm so gestaltet, dass es möglichst unlesbar ist, indem mit entsprechenden Definitionen gearbeitet wurde, welche anschließend im Quelltext genutzt werden.

#define yeet int
#define Yeet main
#define yEet std
#define yeEt cout
#define yeeT return
#define Yeeet (
#define yeeeT )
#define Yeeeet {
#define yeeeeT }
#define yyeet <<
#define yet 0
#define yeett "Yeet!"
#define yeetT ;
#define yEEt ::

Es zeigt auf, dass ohne einheitliche Coding Conventions im besten Fall Chaos droht. Auf die Spitze treibt das auch der International Obfuscated C Code Contest, bei welchem es darum geht, Quelltext möglichst so zu verschleiern, dass nur schwer zu erraten ist, welche Funktion dieser am Ende in sich trägt.

Eine Implementation des zcat-Kommandos

In diesem Beispiel wird der Befehl zcat zur Darstellung mittels gz-komprimierter Daten implementiert. Auch ohne solche Extrembeispiele würde in einer Welt ohne Coding Conventions eine Menge an inkonsistentem Code entstehen:

int counterServer = 1               ;
int counterClient = 2               ;
int counterDevice = 3               ;
int test1 = 4                       ;

Natürlich kann ein Quelltext so formatiert werden, aber in den meisten Fällen erschwert dies die Lesbarkeit des Quelltextes enorm. Auch die Nutzung von Whitespaces und falscher Einrückung kann zu Problemen führen:

if        (system==true) {
    doSomething()        ;
doFoobar                       ();
}

Auch Richtlinien über Komplexität sind ein wichtiger Bestandteil, solcher Konventionen. Gegeben sei folgendes Programm:

#include

main(){
  int x=0,y[14],*z=&y;*(z++)=0x48;*(z++)=y[x++]+0x1D;
  *(z++)=y[x++]+0x07;*(z++)=y[x++]+0x00;*(z++)=y[x++]+0x03;
  *(z++)=y[x++]-0x43;*(z++)=y[x++]-0x0C;*(z++)=y[x++]+0x57;
  *(z++)=y[x++]-0x08;*(z++)=y[x++]+0x03;*(z++)=y[x++]-0x06;
  *(z++)=y[x++]-0x08;*(z++)=y[x++]-0x43;*(z++)=y[x]-0x21;
  x=*(--z);while(y[x]!=NULL)putchar(y[x++]);
}

Bei diesem handelt es sich um ein einfaches Hello World-Programm, aber das Verständnis wird durch die Umsetzung, genauer gesagt dessen unnötige Komplexität, sehr erschwert.

Auch wenn sich auf Einrückungen geeinigt wird, ist dies nicht immer sinnvoll:

function f() {
  doThings();
  doMoreThings();
             }

Bei diesem Beispiel wird eine Einrückung genutzt, welche ungebräuchlich ist und bei den meisten Entwicklern wahrscheinlich auf Ablehnung stoßen wird und nicht dazu führt, dass der Quelltext übersichtlicher wird.

Die Benamung von Elementen ist ein wichtiger Teil von Coding Conventions:

void doSomeTHING() {
  int test1 = 1;
  int TEST2 = 2;
  int teST3 = 3;
}

void DoSomething() {
  int tEST4 = 4;
}

Wird bei dieser nicht auf Konsistenz geachtet, trägt dies nicht zum besseren Verständnis bei. Auch Kommentare, bzw. das Schreiben derselben sind eine Aufgabe, bei der sorgfältig gearbeitet werden sollte:

try {
  ...
} catch(Exception e) {
  // Gotta Catch 'Em All
}

Natürlich ist Humor im echten Leben wichtig, aber in einem Quelltext sollte er nichts zu suchen haben. Stattdessen sollte sich hier auf die Fachlichkeit bezogen werden.

Auch die Nutzung unüblicher Vorgehensweisen bzw. das Verstecken bestimmter Operationen erschwert das Verständnis eines Quelltextes:

int main() {

  String helloWorld = "Hello World!";
  cout << helloWorld << endl;

  String hello = (helloWorld, 5);
  cout << hello << endl;

  system("pause");
  return 0;
}

Ohne weitere Informationen ist es relativ schwer herauszufinden, was in diesem Beispiel passiert. Hier werden die ersten fünf Stellen der Zeichenkette Hello World! zurückgegeben. In diesem Fall geschieht dies über die Überladung des Komma-Operators:

using namespace std;

#define String string

String operator,(String lhs, int rhs) {
  lhs.erase(lhs.begin() + rhs, lhs.end());
  return lhs;
}

Auch eine schlechte Benennung und ein Sprachmischmasch kann das Verständnis des Quelltextes erschweren:

#include 

gibHalloWeltAus()
{
    // use cout for output
    cout << "Hello World!" << endl;

    // Rückgabereturn
    return 0;
}

Ziele von Coding Conventions

Wenn sich diese Beispiele aus der Welt ohne Coding Conventions angeschaut werden, können aus diesen einige Ziele für entsprechende Konventionen abgeleitet werden.

Es geht darum, dass Coding Conventions bewährte Praktiken abbilden und für einen lesbaren und verständlichen Quelltext sorgen. Sie sollen die Zusammenarbeit im Team erleichtern und eine gewisse Einheitlichkeit herstellen.

Daneben sind Coding Conventions und das Konzept von Clean Code miteinander verbunden. Clean Code ist ein Konzept, das sich auf die Softwareproduktion und das Programmierdesign bezieht. Es legt fest, dass Quelltext so geschrieben werden sollte, dass er einfach zu lesen, zu verstehen und zu warten ist. Die Einhaltung von Coding Conventions kann dazu beitragen, diese Kriterien einzuhalten.

Elemente von Coding Conventions

Doch woraus genau bestehen Coding Conventions im Einzelnen? Im ersten Schritt sollte sich bewusst gemacht werden, dass sich solche Konventionen von Sprache zu Sprache unterscheiden. Auch wenn sich im Laufe der Zeit einige Standards herauskristallisiert haben, können diese nicht immer eins zu eins auf die eigenen Anforderungen angewendet werden.

Unterschiedliche Elemente von Coding Conventions

Im Einzelnen setzen sich Coding Conventions aus Elementen zusammen, welche im folgenden genauer besprochen werden sollen.

Benamung

Ein essenzielles Element ist die Benamung innerhalb eines Entwicklungsprojektes. Dies fängt bei Dateinamen und Verzeichnissen an, zieht sich hin zu Bezeichnern, wie den Namen von Variablen, Klassen und vielen anderen Elementen.

Grundsätzlich sollte bei der Benamung von Elementen immer so viel wie nötig und so wenig wie möglich benannt werden.

Dateinamen

Da Coding Conventions sich von Sprache zu Sprache unterscheiden, existieren bereits Unterschiede auf Ebene der Dateinamen. Während Dateien von C-Programmen meist in Kleinschreibung benannt werden:

main.c
tilerenderer.c

sieht dies bei Java-Applikationen anders aus:

Main.java
TileRenderer.java

Neben den Dateinamen bezieht sich dies auch auf die Benamung und Struktur von Verzeichnissen. In C würde dies wie folgt aussehen:

src
  engine
  renderer
  utils

während in Java meist die Struktur des Packages abgebildet wird. Bei dem Package com.example.transformer.html würde die entsprechende Verzeichnisstruktur wie folgt aussehen:

src
  main
    java
      com
        example
          transformer
            html
            markdown
  test

Eine weitere Eigenart von Java ist, dass die Namen der Packages eine Domain-Struktur abbilden und z. B. mit der Domain der Firma beginnen.

Neben den Coding Conventions für die jeweilige Sprache gehen bei der Strukturierung des Projektes auch noch andere Aspekte ein. Wird z. B. mit dem Build-Werkzeug Maven gearbeitet, so gilt dort Konvention vor Konfiguration.

Bei Maven bedeutet dies, dass eine Reihe von Standardregeln existieren, die vom Benutzer des Werkzeuges befolgt werden müssen, um ein Projekt erfolgreich zu erstellen. So muss ein Projekt in einer bestimmten Struktur organisiert sein, damit Maven es erfolgreich verarbeiten kann. Diese Standards erleichtern es, ein Projekt mit Maven zu erstellen, da der Benutzer nicht jeden einzelnen Schritt konfigurieren muss.

Sprechende Namen

Auch bei der Benamung sollten gewissen Standards eingehalten werden:

int a = getSum();

In diesem Fall wird eine Methode mit dem Namen getSum aufgerufen und das Ergebnis in der Variable a gespeichert. Hier sollte mit sprechenden Namen gearbeitet werden. Solche Namen zeichnen sich dadurch aus, dass sie beim Lesen bereits Aufschluss über ihre Fachlichkeit und deren Bedeutung geben:

int sum = getSum();

Damit wird klar, dass sich in der Variable sum eine entsprechende Summe befindet. Theoretisch kann die Benennung natürlich noch weiter spezifiziert werden:

int sumArticles = getSum();

Unter Umständen können Namen hierbei etwas länger werden, aber dafür wird Klarheit gewonnen. Diese Art der Benamung sollte nicht nur für Variablen, sondern generell für Bezeichner, wie Klassennamen gelten.

Allerdings keine Regel ohne Ausnahme, z. B. bei Exceptions unter Java:

try {
  // Try some funky stuff
} catch(Exception e) {
  // Handle exception
}

Dort hat es sich eingebürgert, einer Exception den Namen e bzw. ex zu geben. Sind solche Konventionen vorhanden und weitverbreitet, sollten diese entsprechend eingehalten werden. Auch hier dient das Einhalten dieser Regeln dazu, die Lesbarkeit und Wartbarkeit des Quelltextes zu erhöhen.

Verbotene Bezeichner

Es gibt eine Reihe von Bezeichnungen, welche in der Theorie, je nach verwendeter Sprache, verwendet werden können, es aber nicht sollten.

So ist es in Sprachen wie C# möglich, mit einem vorgestellten At-Zeichen Schlüsselwörter der Sprache als Bezeichner verwenden zu können. Um Verwirrung und darauf aufbauende Probleme zu vermeiden, sollte dies unterlassen werden.

Andere Bezeichner, wie handle, sollten nur in einem eng begrenzten Kontext oder einer entsprechenden Fachlichkeit benutzt werden.

Auch die Nutzung von Variablen mit dem Namen temp oder tmp sollte unterlassen werden, da meist eine entsprechend sinnvollere fachliche Benamung möglich ist.

Schleifen und Benamung

Wie bei Exceptions haben sich auch bei Schleifen bestimmte Konventionen zur Benamung eingebürgert, an welche sich gehalten werden sollte:

for(int i = 0; i < 10; i++) {

    for(int j = 0; j < 10; j++) {

      // Do stuff
    }
}

So wird die Zählervariable bei Schleifen mehrheitlich mit dem Namen i benannt und wenn in der Schleife weitere Schleifen geschachtelt werden, so werden diese fortlaufend mit j, k und so weiter benannt.

Aber auch hier kann in Ausnahmen davon abgewichen werden. Ein Beispiel hierfür wäre z. B. die Verarbeitung eines Bildes:

for(int y = 0; y < image.height; y++) {

    for(int x = 0; x < image.width; x++) {

      // Do image stuff
    }
}

Hier wird sich auf die x- und y-Achse des Bildes bezogen und durch die entsprechende Benamung kann sinnvoll mit diesen in der eigentlichen Logik der Schleife gearbeitet werden.

Kamele, Dromedare und Schlangen

Bezeichner können wie bei obigem Beispiel einfache Namen bestehend aus einem Wort sein, bestehen aber in vielen Fällen aus mehreren Wörtern.

Unterschiedlichste Schreibvarianten bei zusammengesetzten Bezeichnern

Um diese sinnvoll miteinander zu verbinden werden je nach Sprache unterschiedliche Varianten von Binnenmajuskeln benutzt, welche je nach Verwendung treffende Namen wie CamelCase und Ähnliche tragen. Diese Schreibweise sorgt letztlich für eine bessere Lesbarkeit, da sie einzelne Wörter sinnvoll voneinander abgrenzt.

Binde- und Unterstriche

Neben der Schreibweise mittels Binnenmajuskeln existieren auch andere Schreibweisen, was sich im Beispiel wie folgt darstellt:

do_things_fast();
do-things-fast();

So wird in Sprachen wie C und Perl auch auf Unterstriche zurückgegriffen und auch in PHP war dies bis zur Version 4 der Fall. Die Schreibweise mit dem Bindestrich, welche auch als lisp-case bekannt ist, wurde unter anderem in COBOL und Lisp genutzt.

Auch bei Rust wird teilweise auf Unterstriche als auch auf CamelCase gesetzt.

Ausnahmen bei der Benamung

Je nach Sprache wird damit meist eine bestimmte Schreibweise für Bezeichner wie den Namen von Variablen genutzt, allerdings existieren hiervon auch Ausnahmen bzw. Abweichungen, wie bei der Definition von Konstanten:

public static final String SECRET_TOKEN = "X7z4nhty3287";

Diese werden in vielen Fällen komplett großgeschrieben und meist mit Unterstrichen unterteilt. Auch hier gilt wieder, dass solche Konstanten möglichst sprechend benannt werden sollten und auf Abkürzungen und Ähnliches verzichtet werden sollte.

Prä- und Suffixe

In der Vergangenheit wurden an Bezeichner teilweise Prä- und Suffixe mit angetragen. Begründet war dies mit den damaligen Compilern und der fehlenden Unterstützung in der Entwicklungsumgebung. Durch die Nutzung eines Präfixes konnte so z. B. der Typ einer Variable aus dem Namen ermittelt werden.

Die sicherlich bekannteste Notation ist die Ungarische Notation. Hier werden die Bezeichner aus einem Präfix für die Funktion, einem Kürzel für den Datentyp und einem Bezeichner zusammengesetzt.

Ein Beispiel für einen solchen Namen wäre die Variable idValue, welche anzeigt, dass es sich um einen Index vom Typ Double handelt, welcher den Namen Value trägt.

Mittlerweile wird diese Notation in der Praxis nur noch selten genutzt. Auch Linus Torvalds hatte sich dazu geäußert:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged – the compiler knows the types anyway and can check those, and it only confuses the programmer.

Neben der besseren Unterstützung der IDEs gibt es andere Gründe, welche gegen eine Nutzung der ungarischen Notation sprechen. So kann z. B. bestehender Quelltext schlechter migriert werden, wenn sie die Namen nicht ändern dürfen, aber die Typen dies tun. Dies war z. B. der Fall bei der Umstellung der WinAPI auf eine 64-Bit fähige API, bei dem Namen nun nicht mehr auf den korrekten Datentyp hinweisen.

Einrückungen

Neben der Benennung von Bezeichnern ist auch die Einrückung ein unter Umständen recht emotionales Thema.

Dabei geht es hauptsächlich darum, ob Leerzeichen oder Tabulatoren für die Einrückungen genutzt werden. Aus pragmatischer Sicht sollte hier insbesondere die Mischung dieser beiden Varianten verhindert werden.

Für Leerzeichen spricht, dass die Einrückungen bei allen Nutzern identisch aussehen. Im Gegensatz zu Tabulatoren benötigen Leerzeichen, mehr Speicher. Vier Leerzeichen belegen 4 Byte, ein Tabulator nur ein Byte.

Bei Tabulatoren kann der Einzug in der Entwicklungsumgebung individuell konfiguriert werden, was aber gleichzeitig den Nachteil ergibt, dass der Quelltext bei unterschiedlichen Mitarbeitenden anders aussehen kann.

Persönlich würde der Autor an dieser Stelle immer Leerzeichen empfehlen. Damit ist ein Quelltext gewährleistet, welcher bei jedem Entwickler identisch aussieht. Der zusätzliche Speicherbedarf kann hierbei vernachlässigt werden.

Einrückungstiefen

Bei der Frage der Leerzeichen stellt sich auch die Frage, mit wie vielen Leerzeichen soll ein Block eingerückt werden. Hier ergibt sich die Möglichkeit, dies mit zwei Leerzeichen je Block zu machen:

void main() {
  doSomething();
}

Der Standard bei vielen Projekten sind hingegen vier Leerzeichen:

void main() {
    doSomething();
}

Allerdings sind auch acht Leerzeichen gebräuchlich, z. B. beim Linux-Kernel. Wirklich bemerkbar wird dies allerdings erst dann, wenn mehrere Blöcke ineinander verschachtelt werden:

void main() {

    for(int i = 0; i < 10; i++) {

        for(int j = 0; j < 10; j++) {

            doSomething();
        }
    }
}

Je nach Ausgabeformat, z. B. beim Ausdruck oder in Präsentationen ist es sinnvoll auf zwei Leerzeichen zu setzen, aber im Allgemeinen sollten vier Leerzeichen genutzt werden.

Whitespaces und Leerzeilen

Neben der Einrückung sind auch die Whitespaces im Quelltext selbst, sowie Leerzeilen ein Element zur Strukturierung des Quelltextes.

Leerzeilen stellen ein wichtiges Element zur Strukturierung dar. Natürlich kann ein Quelltext ohne Leerzeilen geschrieben werden und leider ist dies in der Praxis oft zu sehen. Sinnvoll ist es aber, den Quelltext etwas weiträumiger zu gestalten:

int getResult(int a, int b) {

    int sum = getSum();
    int ret = 0;

    for(int i = 0; i < 10; i++) {
        ret += sum;
    }

    return ret;
}

Die Trennung einzelner Bestandteile des Quelltextes durch Leerzeilen sollte anhand der funktionalen Blöcke bzw. nach der Fachlichkeit vorgenommen werden.

Neben den Leerzeilen, sind auch Whitespaces ein essenzieller Teil der Formatierung eines Quelltextes. Whitespaces definieren sich allgemein als Leerstellen in Text, Code oder Schrift, die zwischen Zeichen, Wörtern, Zeilen oder Absätzen liegen. In der Programmierung werden Whitespaces auch als Formatierung verwendet, um den Quelltext leserlicher zu machen und den Code übersichtlicher zu strukturieren.

Whitespaces verbessern die Sichtbarkeit und das Verständnis der Syntax:

int sum=a+b;

for(int i=0;i<10;i++) {
    doSomething();
}

Bei diesem Beispiel wäre es wesentlich sinnvoller, Leerzeichen zum Strukturieren zu nutzen und dem Quelltext eine gewissen Luftigkeit zu geben:

int sum = a + b;

for(int i = 0; i < 10; i++) {
    doSomething();
}

Dies erhöht die Lesbarkeit und sorgt letztlich für ein besseres Verständnis. Natürlich kann auch an dieser Stelle übertrieben werden:

for ( int i = 0; i < 10; i++ ) {
    doSomething ( ) ;
}

So werden hier auch Leerzeichen rund um die Klammern gesetzt, was im Normalfall nicht sonderlich hilfreich ist und deshalb unterlassen werden sollte.

Blockklammern

In vielen Programmiersprachen wird mit Blöcken gearbeitet. Ein Block definiert sich als eine Gruppe von Anweisungen, die als eine Einheit behandelt werden. So wird über den Block z. B. der Gültigkeitsbereich von Variablen definiert. Ein Block beginnt normalerweise mit einer öffnenden geschweiften Klammer und endet mit einer schließenden Klammer gleichen Typs.

Beispielsweise kann ein Block zu einer if-Anweisung gehören, in der eine Reihe von Anweisungen ausgeführt werden, wenn die Bedingung wahr ist. Hier kann natürlich die Frage nach der Notwendigkeit gestellt werden, wie in diesem Stück Java-Code:

if(something == true)
    doFooBar();

So würde dieses Beispiel ohne Probleme kompilieren und wenn die Bedingung zutrifft, die Methode doFooBar aufgerufen werden. Problematisch wird dieses Konstrukt allerdings dann, wenn der Quelltext an dieser Stelle erweitert wird:

if(something == true)
    doAnotherThing();
    doFooBar();

Nun würde nur noch die Methode doAnotherThing ausgeführt werden. Die andere Methode hingegen nicht mehr. Aus dem Quelltext ist dies allerdings nicht ohne Weiteres ersichtlich. Aus diesem Grund sollte immer mit Blockklammern gearbeitet werden, auch wenn nur eine einzelne Anweisung folgt:

if(something == true) {
    doFooBar();
}

Dadurch werden Fehler vermieden und die Intention des Quelltextes wird sofort ersichtlich.

Position der Klammern

Für die Positionierung der geschweiften Blockklammern gibt es in der Praxis zwei verbreitete Varianten, diese zu setzen. Bei der ersten Variante sind sie beide auf der gleichen Ebene zu finden:

boolean get()
{
    int a = 7;
    int b = 42;

    int result = doFooBar(7, 42);

    if(result == 23) 
    {
        return false;
    }

    return true;
}

Der Vorteil an dieser Variante ist, dass sofort zu sehen ist, wo ein Block beginnt und wo sich die entsprechende schließende Klammer des jeweiligen Blockes befindet. Als Nachteil wird bei dieser Variante oft aufgeführt, dass damit etwas Platz verschwendet wird.

Bei der anderen gebräuchlichen Variante wird die öffnende Klammer eines Blockes direkt hinter die Anweisung gesetzt, welche zum öffnenden Block gehört:

boolean get() {

    int a = 7;
    int b = 42;

    int result = doFooBar(7, 42);

    if(result == 23) {
        return false;
    }

    return true;
}

Dies erschwert zwar die Zuordnung zwischen dem Beginn des Blockes und dem Ende, allerdings zeigen die meisten modernen IDEs diese Zuordnung prominent an.

In der Theorie wird bei dieser Variante eine Zeile eingespart, allerdings ist es sinnvoll nach der öffnenden Blockklammer eine Leerzeile zu setzen, um die Übersichtlichkeit zu erhöhen.

Häufig wird noch ein Unterschied zwischen einzeiligen und mehrzeiligen Blöcken gemacht:

if(something == true) {
    doFooBar();
}

Dort wird die Leerzeile weggelassen, während sie bei mehrzeiligen Blöcken immer eingefügt wird:

if(something == true) {

    doFooBar();
    doSomething();

    for(int i = 0; i < 10; i++) {
        doThings();
    }    
}

Blöcke per Einrückung

Neben Sprachen mit solchen Blockklammern existieren auch Sprachen wie Python, welche andere Wege zur Strukturierung von Blöcken nutzen:

import sys
import random

running = True

while running:

    randomNumber = random.randint(0,8)

    if randomNumber == 0:
        break;
        
    else:
        print(randomNumber)

Hier wird die Zuordnung zu einem Block über die entsprechende Einrückung vorgenommen. Damit entfällt die Frage nach der Position der Blockklammern.

Reihenfolgen

In vielen Programmiersprachen gibt es Schlüsselwörter, wie Modifikatoren für die Sichtbarkeit. Für diese empfiehlt es sich auch eine entsprechende Reihenfolge zu definieren und diese einzuhalten.

Am Beispiel von Java wäre dies die Sichtbarkeit, dann eine eventuelle static-Definition gefolgt von einer final-Definition und am Ende der eigentlichen Definition:

public int a = 7;
public final int b = 24;
public static final int c = 42;

Auch bei Systemen zur statischen Codeanalyse, wie Sonarlint, sind solche Regeln hinterlegt.

Reihenfolge im Quelltext

Neben den Namen der Bezeichnern sind je nach Sprache auch bestimmte Reihenfolgen der einzelnen Elemente gewünscht. Unter Java ist dies vornehmlich folgende Reihenfolge: Konstanten, private Variablen, private Methoden, Getter und Setter und anschließend öffentliche Methoden.

Allerdings kann es valide sein, Public-Methoden und Private-Methoden zusammenzuhalten, wenn diese z. B. nach Funktionalität gruppiert sind.

Zeilenlänge und Umbrüche

Früher gab es relativ strenge Regeln, was die maximale Zeilenlänge innerhalb eines Quelltextes anging. Meist waren dies 80 Zeichen pro Zeile, bedingt durch die 80 Spalten in der Hollerith-Lochkarte von IBM. Daneben haben sich mittlerweile Zeilenlängen von 80 über 100 bis zu 120 Zeichen pro Zeile eingebürgert.

Auch in Zeiten größerer Bildschirme und höherer Auflösungen, sollten Zeilen trotzdem nicht unendlich lang gestaltet werden, sondern mit Zeilenumbrüchen gearbeitet werden. Für solche Umbrüche existieren unterschiedliche Variante, welche in gewisser Hinsicht Geschmacksache sind.

public int calculate(int valueA,
                     int valueB,
                     int valueC,
                     int valueD,
                     int valueE,
                     int valueF,
                     int valueG) {
    return 0;
}

Grundsätzlich sollten keine Umbrüche mitten in einer Parameterliste vorgenommen werden, sondern die Parameter einzeln umgebrochen werden. Auch bei Fluent Interfaces wird mit Zeilenumbrüchen gearbeitet:

CarBuilder carBuilder = new CarBuilder()
        .withWheels(4)
        .withEngine(400, Fuel.DIESEL)
        .withWindows(5)
        .build();

Die Umbrüche verbessern, richtig eingesetzt, die Lesbarkeit und Verständlichkeit des Quelltextes.

Kommentare

Für einen verständlichen Quelltext sind in vielen Fällen Kommentare in diesem nötig und wichtig.

Je nach Sprache werden unterschiedliche Möglichkeiten für Kommentare bereitgestellt. Vorwiegend sind dies Zeilenkommentare und Blockkommentare.

Blockkommentare sind eine Reihe von Kommentaren, die durch ein vorangestelltes /* und ein abschließendes */ angezeigt werden, sodass mehrere Zeilen Text zusammen kommentiert werden können. Zeilenkommentare sind Kommentare, die nur eine einzelne Zeile betreffen und mit // beginnen. Sie können am Ende einer Codezeile oder auf einer eigenen Zeile platziert werden. Beide Kommentartypen sind nützlich, um das Verständnis des Codes zu erleichtern, indem sie Erklärungen zu bestimmten Codeabschnitten bereitstellen.

In den meisten Fällen sollten innerhalb eines Quelltextes den Zeilenkommentaren der Vorrang eingeräumt werden, entweder zum Auskommentieren von Quellcode oder zum Dokumentieren innerhalb des Codes:

// Create system temporary directory
Path tmpdir = null;

// log.error(tmpdir);

Block-Kommentare werden oft für die Dokumentation von Methoden, z. B. mittels JavaDoc genutzt:

/**
 * This method returns an Optional that holds a String containing
 * the file extension of the passed filename.
 * @param filename The file name whose extension is to be determined.
 * @return Optional filled with a String with the file extension if 
 * the file has an extension, or an empty optional if it has no extension.
 */

Grundsätzlich gilt bei Kommentaren, dass sie fachlicher Natur sein sollten und dass nicht unnötig kommentiert wird. Als Sprache bietet sich hier wie bei der Benamung von Bezeichnern Englisch als kleinster gemeinsamer Nenner an. Unnötige Kommentare sollten vermieden werden:

// Calculate sum and store in sum
int sum = getSum(a, b);

Der Inhalt des Kommentars ergibt sich bereits aus der sprechenden Bezeichnung der Variablen und der dazugehörigen Methode, sodass dies nicht noch einmal mit einem Kommentar untermauert werden muss.

Interessanter wäre es hier, wenn der Kommentar noch etwas zur Fachlichkeit beiträgt:

// Calculate sums of base articles
int sum = getSum(a, b);

Auch das beliebte Auskommentieren von Code wird mittels der Sprachmittel des Kommentars ermöglicht. Im Normalfall sollte auskommentierter Quellcode am Ende immer entfernt werden und nicht im Quelltext verbleiben.

Allgemeine Regeln

Neben Regeln für spezielle Konstrukte existieren eine Reihe von allgemeinen Regeln, welche auch in Coding Conventions Einzug gefunden haben.

So gilt, dass pro Zeile genau eine Anweisung bzw. ein Statement kodiert wird, eine Funktion bzw. eine Methode genau eine Aufgabe erledigen und Klassen und Methoden eine gewisse Größe nicht überschreiten sollten.

Bei Klassen definiert sich hier meist eine maximale Größe von 2000 Zeilen, während bei Methoden gerne gesagt wird, dass eine Methode als Ganzes auf den Bildschirm passen sollte.

Aufgaben für Methoden

Auch die Beschränkung von Methoden auf eine Aufgabe ist eine sinnvolle Regel. So verheißt eine Methode mit dem Namen doItAll() schon wenig Gutes. Hingegen definiert folgende Methode:

int getSum(int a, int b)

schon anhand ihres Namens klar, welche Aufgabe sie wahrnimmt und mit welchem Ergebnis zu rechnen ist.

Dadurch, dass Funktionen bzw. Methoden sich nur auf eine Aufgabe beschränken, sind sie besser wiederverwendbar und verhindern in vielen Fällen doppelten Quelltext. Auch das Review solcher fachlich eng abgestimmten Methoden ist einfacher möglich, da die Komplexität verringert ist.

Coding Conventions

Während bis hierhin viele einzelne Elemente beschrieben wurden, sollen diese nun zu einer Coding Convention zusammengeführt werden. Solche Coding Conventions sind relativ umfangreiche Werke. In vielen Fällen ist es nicht nötig das Rad neu zu erfinden, da für viele Sprachen Standard-Konventionen existieren, welche genutzt werden können.

Alternativ sollte sich zumindest an diesen Konventionen orientiert werden. Auch die jeweiligen Entwicklungsumgebungen, setzten über die Code-Formatierung gewisse Teile von Coding Conventions direkt um.

Sprachspezifische Konventionen

Wer sich umschaut, wird feststellen, dass eine Reihe von Coding Conventions für unterschiedliche Sprachen existieren. Dies sind unter anderem die .NET: Microsoft Coding Conventions, für Java die Code Conventions for the Java Programming Language und für PHP: PSR-1 und PSR-2.

Allerdings werden manche dieser Konventionen wie für Java mittlerweile als veraltet angesehen und büßen damit auch an Verbindlichkeit ein. Bei anderen Styles wie PSR-2 werden diese direkt für die Entwicklung des Frameworks genutzt und sind somit verbindlich.

Übergreifende Konventionen

Daneben existieren noch andere Coding Conventions wie die Apple Coding Convention und der Google Style Guide.

Der Google Style Guide deckt Konventionen für unterschiedlichste Sprachen, wie C++, Objective-C, Java, Python, R, HTML, JavaScript und weitere ab und kann online eingesehen werden.

Lizenziert ist der Google Style Guide unter der Creative-Commons-Lizenz CC-BY. Neben der eigentlichen Beschreibung werden auch Dateien mit den entsprechenden Konfigurationen für die Entwicklungsumgebung mitgeliefert.

Dokumentation

Auch wenn ein Hauptaugenmerk bei Coding Conventions auf dem Quelltext liegt, sollte die Dokumentation ebenfalls beachtet werden. So sollte nur das notwendige dokumentiert und tote und inkorrekte Dokumentation gelöscht werden.

Auch hat es sich eingebürgert, eine entsprechende Datei ins Wurzelverzeichnis des Projektes zu legen. Diese trägt meist den Namen README bzw. README.md

In diesem Dokument wird erklärt, um welches Projekt es sich handelt und ein kurzer Überblick über das Projekt gegeben. Daneben werden weiterführende Links bereitgestellt und erklärt, wie das Projekt gebaut werden kann.

# WordPress2Markdown

WordPress2Markdown is a tool that convert WordPress eXtended RSS (WXR) into markdown. Export the WordPress site via
backend and use the WordPress eXtended RSS (WXR) with this tool.

## Usage

WordPress2Markdown is a command line tool.

> java -jar WordPress2Markdown.jar -i wordpress-export.xml -s DATETIME -o /home/seeseekey/MarkdownExport

### Parameter

The options available are:

    [--author -f value] : Filter export by author
    [--authors -a] : Export authors
    [--help -h] : Show help
    [--input -i value] : Input path
    [--output -o value] : Output path
    [--scheme -s /POST_ID|DATETIME/] : Scheme of filenames

## Conversion

WordPress2Markdown converted the following html and other tags:

* \<em\>
* \<b\>
* \<blockquote\>
* \<pre\>
* \<img\>
* \<a\>
* Lists
* WordPress caption blocks ()

All other tags are striped.

## Developing

Project can be compiled with:

> mvn clean compile

Package can be created with:

> mvn clean package

## Authors

* seeseekey - https://seeseekey.net

## License

WordPress2Markdown is licensed under AGPL3.

Eine weitere wichtige Datei ist das Changelog, bzw. die Datei CHANGELOG.md. Diese Datei dokumentiert Änderungen am Projekt und informiert den Leser somit über Änderungen, neue Funktionalität und Ähnliches.

# Changelog

This changelog goes through all the changes that have been made in each release.

## [1.2.0-SNAPSHOT]() - 2022-03-04

### Added

* Implement simple conversion for CSV files

### Changed

* Update project to Java 17
* Rework changelog
* Update dependencies
* Change license from GPL3 to AGPL3

### Fixed

* Fix some SonarLint code smells
* Small optimizations

## [1.1.0](https://github.com/seeseekey/Convert2Markdown/releases/tag/v1.1) - 2019-10-13

### Added

* Implement conversion of MediaWiki dump files
* Add statistical information for export
* Add support for exporting author (#1)
* Add filter to export only a specific author

### Changed

* Rename tool to Convert2Markdown
* Update documentation
* Rebuild HTML to markdown conversion with HTML parser

## [1.0.0](https://github.com/seeseekey/Convert2Markdown/releases/tag/v1.0) - 2019-03-26

* Initial release

Versionierung

Im weiteren Sinne gehört auch die Versionierung des Projektes zu den Coding Conventions. Gerne genutzt wird hierbei die semantische Versionierung. Dabei liegen den Zahlen der Versionnummer z. B. 2.4.7 eine bestimmte Bedeutung zugrunde.

So handelt es sich bei der ersten Zahl um die Major-Version, welche nur dann erhöht wird, wenn zur Vorgängerversion inkompatible Änderungen oder andere signifikanten Änderungen vorgenommen wurden.

Die zweite Zahl ist die sogenannte Minor-Version, welche meist bei neuer Funktionalität hochgezählt wird. Die letzte Zahl bezeichnet die Bugfix-Version und wird bei entsprechenden Fehlerbereinigungen hochgezählt.

Daneben existieren auch andere Versionierungen, wie das relativ beliebte Schema Jahr.Monat z. B. 2023.04 als Versionnummer, welche bei neuen Releases basierend auf der Version gerne um eine dritte Nummer erweitert werden z. B. 2023.04.1.

Umsetzung

Neben der eigentlichen Definition einer Coding Conventions ist es wichtig, dass diese im Entwicklungsalltag berücksichtigt und genutzt wird. Hier stellt sich dann die Frage nach der organisatorischen Umsetzung.

Grundlegend sind es einige Schritte auf dem Weg bis zu Nutzung und Umsetzung. So sollte sich im ersten Schritt auf eine Coding Convention geeinigt werden. Nachdem dies geschehen ist, mitsamt aller diesbezüglicher Regeln, wie zur Benennung oder der gewünschten Komplexität, müssen diese Coding Conventions entsprechend kommuniziert werden.

So ist es problemlos möglich, entsprechende Templates für die Einstellungen der jeweiligen IDEs zur Verfügung zu stellen. Auch sollte die Überprüfung der Coding Conventions beim Review kontrolliert werden.

Daneben können die entsprechenden Coding Conventions auch per Software überprüft und z. B. das Pushen in ein entferntes Git-Repository nur erlaubt werden, wenn die Coding Conventions eingehalten wurden. Allerdings sollte auch nicht versucht werden, soziale Probleme, welche sich bei der Einführung der Konventionen ergeben, durch rein technische Ansätze zu lösen.

Umstellung

Eine weitere Frage ist die Umstellung der bestehenden Projekte auf neue Coding Conventions. Bestimmte Dinge wie die Formatierung des Quelltextes können meist automatisch auch für größere Projekte bewerkstelligt werden.

Daneben sollte bestehender Code Stück für Stück auf die Konventionen angepasst werden, z. B. bezüglich der Benamung. Dies kann immer dann geschehen, wenn an einer entsprechenden Stelle im Rahmen einer Anforderung gearbeitet wird.

Probleme

Natürlich kann es bei der Nutzung und Einführung von Coding Conventions Probleme geben. Dies kann sich in Widerstand aus der Entwicklerschaft oder in Problemen mit der technischen Seite wie unterschiedlicher IDEs ausdrücken.

Vor allem bei einer Neueinführung kann es schwierig sein, sich an entsprechende Konventionen und Regeln zu gewöhnen, wenn vorher ohne gearbeitet wurde. Das Gleiche gilt, wenn eine Konvention nicht den eigenen Präferenzen entspricht.

Es kann passieren, dass einige Zeit dafür aufgebracht werden muss, die Konventionen zu verinnerlichen und umzusetzen. Deshalb ist es wichtig, die Konventionen klar zu kommunizieren, ihre Nutzung verpflichtend zu machen und dies im Entwicklungsprozess wie beim Review auch zu beachten.

Fazit

Coding Conventions sind ein wesentlicher Bestandteil der Softwareentwicklung und bieten viele Vorteile. Sie helfen dabei, Quelltexte einfacher lesbar, verständlich und wiederverwendbar zu machen. Dadurch wird die Wartbarkeit verbessert und die Qualität der Software erhöht. Dies kann zu einer höheren Produktivität und einem schnelleren Entwicklungsprozess führen.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Selfhosting in fünfter Auflage erschienen

Vor einigen Tagen ist mein Buch Selfhosting: Server aufsetzen und betreiben in der fünften Auflage erschien. Die erste Auflage des Buches erschien im Jahr 2015. Im Gegensatz zu den Vorgängerausgaben, erscheint diese Ausgabe, neben der E-Book-Variante, auch gedruckt als Soft- und Hardcover-Ausgabe. Behandelt wird im Buch der Betrieb eines eigenen Servers mitsamt entsprechender Dienste unter der Nutzung der Linux-Distribution Ubuntu. Neben den bisherigen Inhalten wurde viele Kapitel um entsprechende Hintergründe erweitert.

Selfhosting

Nach einer kurzen Einleitung behandelt das Buch die Beschaffung eines Servers, die anschließende Installation und Grundeinrichtung. Dabei wird auch das Setup von verschlüsselten Servern behandelt. Nach der Vermittlung von Linux– und Netzwerk-Grundlagen, wird anschließend die Einrichtung unterschiedlichster Servertypen, wie Mail-, Game- oder Webserver behandelt. Neben diesen werden Dienste wie Git und XMPP besprochen. In weiteren Abschnitten des Buches wird auf Themen wie das Backup von Servern, die Sicherheit, Wartung und Verwaltung derselben eingegangen.

Die Hard- und Softcover-Ausgaben

Erhältlich ist das Buch als E-Book, sowie in einer Soft- und Hardcover-Variante. Es kann es unter anderem bei Amazon, Beam, Google Play, eBook.de und iTunes bezogen werden. Direkt bestellt werden kann das Buch über den Shop von Tredition.

Fluent Interfaces unter Java

Der Begriff des Fluent Interface hat mittlerweile knapp zwei Jahrzehnte auf dem Buckel und solche Schnittstellen sind mittlerweile auch in größerem Umfang in der Praxis angekommen und werden dort vielfältig genutzt. Trotzdem scheint es manchmal schwer zu fallen genau zu definieren, was ein solches Fluent Interface ist, was es auszeichnet und wie es in der Praxis sinnvoll genutzt werden kann.

Herkunft

Fluent Interfaces, welche wohl holprig mit einer fließenden Schnittstelle übersetzt werden könnten, sind eine Begrifflichkeit, welche in dieser Form erstmals 2005 von Martin Fowler und Eric Evans definiert wurden.

Martin Fowler ist bekannt für seine Arbeit, am Manifest für Agile Softwareentwicklung und seine Bücher, welche unter anderem das Code-Refactoring in die breite Öffentlichkeit trugen und populär machten.

Eric Evans ist vorwiegend für seine Beiträge rund um das Domain-Driven Design bekannt, dessen Gedanken er erstmals im gleichnamigen Buch Anfang der 2000er-Jahre zusammenfasste und somit den Begriff prägte.

Sinnvoller wäre für Fluent Interfaces allerdings die Bezeichnung als sprechende Schnittstelle, welcher eher der Idee im Kern entspricht. Bezugnehmend auf die Wortherkunft aus dem englischen to be fluent in a language, kann allerdings auch im Deutschen von Fluent Interfaces gesprochen werden.

Ideen des Fluent Interfaces

Dem Namen entsprechend ist eines der Ziele eines Fluent Interfaces, APIs besser lesbar und verstehbarer zu gestalten. Daneben soll die API Funktionalitäten passend zum Objekt bereitstellen können.

Bei Betrachtung einer solchen sprechenden Schnittstelle, soll der Quellcode sich wie eine natürliche Sprache bzw. ein Text in einer solchen anfühlen, anstatt eine Reihe von abstrakten Anweisungen darzustellen. Martin Fowler definierte auch ein Maß für diese Fluidität:

The key test of fluency, for us, is the Domain Specific Language quality. The more the use of the API has that language like flow, the more fluent it is.

Ein schönes Beispiel für die Nutzung einer solchen sprechenden Schnittstelle ist die Anwendung des Mock-Frameworks Mockito:

when(uuidGenerator.getUUID()).thenReturn(15);

Auch ohne genauere Kenntnisse über Mockito kann der Programmierer aus diesem Beispiel herauslesen, dass wenn die Methode getUUID angefordert wird, im Rahmen des Mocks immer der Wert 15 zurückgegeben wird.

Die Zeile kann mit sprachlichen Mitteln einfach gelesen werden und verrät dem Nutzer etwas über die dahinterliegende Funktionalität. Das Ziel, die entsprechenden Schnittstellen einfach lesbar und benutzbar zu machen, wird sich dadurch erkauft, dass es meist aufwendiger ist, solche Schnittstellen zu designen und zu entwickeln.

Dies bedingt sich durch das vorher zu durchdenkende Design und einem Mehraufwand beim Schreiben des eigentlichen Quellcodes, unter anderem in Form zusätzlicher Methoden und anderen Objekten zur Abbildung des Fluent Interface.

Zur Implementierung von Fluent Interfaces werden unterschiedliche Techniken wie das Method Chaining genutzt. Daneben werden häufig Elemente wie statische Factory-Methoden und entsprechende Imports, sowie benannte Parameter genutzt.

Sprechende Schnittstellen ermöglichen es auch Personen einen Einblick in den Quellcode zu geben, welche nicht mit den technischen Details desselben vertraut sind. Auch bei der Abbildung von fachlicher Logik helfen Fluent Interfaces, z. B. über entsprechende Methodennamen, welche sich auf die Fachlichkeit der Anwendung beziehen.

Method Chaining

Eine der Techniken zur Erstellung von sprechenden Schnittstellen ist das Method Chaining, welches im Deutschen treffend mit Methodenverkettung übersetzt werden kann.

Methodenketten sind eine Technik, bei der mehrere Methoden aufeinanderfolgend aufgerufen werden, um ein Ergebnis zu erhalten. Beispielsweise könnte ein Entwickler mehrere Methoden aufrufen, um einen bestimmten Wert aus einem Array zu extrahieren oder einen Alternativwert bereitzustellen. Die Methodenketten ermöglichen es dem Entwickler, mehrere Aufgaben in einer Kette zu erledigen, anstatt sie auf getrennte Statements zu verteilen.

Das bedeutetet allerdings im Umkehrschluss nicht, dass die Verkettung von Methoden gleich einem Fluent Interface entspricht, sodass an dieser Stelle immer differenziert werden sollte.

Am Ende einer Methodenkette wird das benötigte Objekt zurückgegeben oder die gewünschte Aufgabe ausgeführt. Aussehen könnte eine solche Methodenkette, in diesem Fall am Beispiel der Stream-API, wie folgt:

User nathalie = Arrays.stream(users)
        .filter(user -> "Nathalie".equals(user.getForename()))
        .findFirst()
        .orElse(null);

Bei solchen Methodenketten gilt es zu berücksichtigen, dass bestimmte Methoden innerhalb der Kette im schlimmsten Fall null zurückgeben oder Exceptions auslösen. Je nach genutztem Interface müssen diese Fälle entsprechend beachtet werden.

Interessanterweise brechen Methodenketten mit einigen älteren Konventionen. So würden z. B. Setter in einem Builder-Pattern:

User.Builder.newBuilder()
               .name("Mustermann")
               .forename("Max")
               .username("maxmustermann")
               .build();

einen Wert zurückgeben, in diesem Beispiel das Builder-Objekt. Im Normalfall würde der Setter stattdessen keinen Rückgabeparameter aufweisen. Er wäre in einem gewöhnlichen Objekt wie folgt definiert:

public void setName(String name) {
    this.name = name;
}

Diese Konvention rührt vom Command-Query-Separation-Pattern, welches besagt, dass entweder Kommandos oder Queries definiert werden sollten. Abfragen als solche, dürfen keinerlei Auswirkungen am Zustand der Klasse haben, während bei Kommandos entsprechende Auswirkungen explizit erwünscht sind. Dies ist z. B. dann der Fall, wenn Daten geändert werden.

Method Nesting

Eine weitere Technik, welche für die Nutzung und das Design von Fluent Interfaces benutzt wird, ist das Method Nesting bzw. das Verschachteln von Methoden. Ein Beispiel hierfür liefert die Java-Bibliothek REST Assured, welche eine domänenspezifische Sprache zur Abfrage und Validierung von REST-Services darstellt:

when()
  .get("https://api.pi.delivery/v1/pi?start=0&numberOfDigits=100").
then()
  .statusCode(200)
  .body("content", startsWith("31415926535897932384"));

Neben der Verkettung von Methoden werden hier auch Methoden ineinander verschachtelt. In diesem Fall wird die startWith-Methode innerhalb der body-Methode geschachtelt, was dafür sorgt, dass beim Lesen ein besseres Verständnis entsteht, was im Quellcode passiert.

Die startWith-Methode stammt hierbei aus dem Hamcrest-Framework, welches viele solcher Methoden, unter anderem zur Nutzung in Unit-Tests, bereitstellt.

Statische Imports

Damit die Sprachelemente der Bibliothek im obigen Beispiel nicht immer voll referenziert werden müssen, werden statische Imports genutzt:

import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;

Damit kann eine statische Methode ohne ihren Klassennamen referenziert und genutzt werden. Ohne diesen statischen Import würde obiges Beispiel etwas umfangreicher aussehen:

RestAssured.when()
  .get("https://api.pi.delivery/v1/pi?start=0&numberOfDigits=100").
then()
  .statusCode(200)
  .body("content", Matchers.startsWith("31415926535897932384"));

Damit wird über den Mechanismus der statischen Importe sichergestellt, dass der Quelltext, im Rahmen der Philosophie der sprechenden Schnittstellen, möglichst lesbar bleibt.

Object Scoping

Vor allem in Programmiersprachen mit einem globalen Namensraum und echten Funktionen können Funktionen, welche einzelne Bestandteile einer domänenspezifischen Sprache darstellen, in diesem globalen Namensraum angelegt werden.

Allerdings ist dies in den meisten Fällen unerwünscht, sodass die Bestandteile der domänenspezifischen Sprache, wie im Beispiel REST Assured in entsprechende Objekte verpackt werden und damit den globalen Namensraum entlasten. Dieses Vorgehen trägt den Namen Object Scoping.

Anwendung

Doch wozu können solche Fluent Interfaces in der Praxis genutzt werden? Unterschiedlichste Szenarien werden immer wieder angesprochen, wenn es um die Nutzung dieser Technik geht.

Eine häufigere Anwendung ist das Builder-Pattern und die Nutzung in Form domänenspezifischer Sprachen kurz DSLs bzw. im englischen Original Domain Specific Languages.

Eine solche domänenspezifische Sprache ist eine Programmiersprache, welche für ein bestimmtes Feld, besagte Domäne, entwickelt wird. Häufig werden sie verwendet, um komplexe Aufgaben zu vereinfachen, indem eine auf die Domäne und die zu lösenden Probleme angepasste Syntax genutzt wird, welche meist große Schnittmengen mit der Fachlichkeit der Domäne beinhaltet.

Fluent Interfaces in der Java-Welt

Auch in der Java Class Library existieren APIs, welche als Fluent Interface angelegt sind. Ein prominentes Beispiel hierfür ist die Stream-API:

User aMustermann = Arrays.stream(users)
        .parallel()
        .filter(user -> "Mustermann".equals(user.getName()))
        .findAny()
        .orElse(null);

Über die Stream-API können unterschiedlichste Anforderungen abgebildet werden. In diesem Fall wird ein Array mit Objekten vom Typ User durchsucht und parallel ein Nutzer mit dem Nachnamen Mustermann gesucht. Dieses Objekt wird dann zurückgegeben. Wird kein solches Objekt gefunden, so wird stattdessen null zurückgegeben.

Auch in anderen Frameworks wie Mocking-Frameworks oder solchen Bibliotheken, welche domänenspezifische Sprachen abbilden, wird intensiv Gebrauch von Fluent Interfaces gemacht.

Frameworks, wie Spring, nutzen ebenfalls interne DSLs, um bestimmte Anforderungen und Möglichkeiten zur Konfiguration abzubilden.

Fluent Interfaces im Builder-Pattern

Eine weitere Anwendung für Fluent Interfaces im weiteren Sinne ist das sogenannte Builder-Pattern. Bei diesem existiert eine Klasse und ein dazugehöriger Builder, welcher dazu dient das Objekt zu konstruieren.

Hier wird ersichtlich, dass dies auf den ersten Blick mehr Aufwand bei der Implementation bedeutet. Allerdings müssen „Standardaufgaben“, wie das Erstellen eines Builders nicht unbedingt von Hand erledigt werden, da es für unterschiedlichste IDEs entsprechende Unterstützung in Form von Erweiterungen gibt. Für IntelliJ IDEA wäre ein Plugin für diese Aufgabe der InnerBuilder von Mathias Bogaert.

Ein Plugin für die einfache Erzeugung von Buildern in IntelliJ IDEA

Mithilfe dieser Plugins können Builder-Klassen schnell erstellt und bei Änderungen der eigentlichen Basisklasse angepasst werden, indem die Builder-Klasse über das Plugin neu generiert wird. Dies ermöglicht eine unkomplizierte Änderung von Klassen samt ihrer dazugehörigen Builder.

Manchmal wird beim Builder-Pattern infrage gestellt, ob es sich bei diesem wirklich um ein Fluent Interface handelt. Dabei wird die Unterscheidung getroffen, dass Fluent Interfaces sich mehr auf die Manipulation und Konfiguration von Objekten konzentrieren, während Builder den Fokus auf die Erzeugung von Objekten legen.

Es stellt sich allerdings die Frage, inwiefern diese Gedanken akademischer Natur, in der Praxis relevant sind, da auch Builder sich aus Sicht des Lesers des Quellcodes gut als Fluent Interfaces erschließen lassen.

Builder-Pattern im Beispiel

Wie könnte ein solches Builder-Pattern nun an einem einfachen Beispiel aussehen? Gegeben sei folgende Klasse:

public class User {

    private String name;

    private String forename;

    private String username;

    public User() {
    }
}

Die Klasse mit dem Namen User enthält drei Felder in welchen der Name, Vorname und der Nutzername des Nutzers gespeichert werden. Um die Felder der Klasse zu befüllen, existieren unterschiedliche Möglichkeiten.

So könnte ein entsprechender Konstruktor definiert werden, welcher diese Felder setzt:

public User(String name, String forename, String username) {
    this.name = name;
    this.forename = forename;
    this.username = username;
}

Dieser könnte nun aufgerufen werden, um eine Instanz der Klasse zu erstellen und die Felder zu füllen:

User max = new User("Mustermann", "Max", "maxmustermann");

Soll jedoch ein Wert nicht gesetzt werden, kann dieser auf null gesetzt werden. Allerdings kann es hier auch den Fall geben, dass mit NotNull-Annotationen und einer entsprechenden Validation gearbeitet wird:

public User(@NotNull String name, @NotNull String forename, @NotNull String username)

Durch die Annotation soll verhindert werden, dass die entsprechenden Felder mit dem Wert null initialisiert werden können. In einem solchen Fall ist für die entsprechenden Felder auch die Anwendung des Builder-Patterns nur schwer vorstellbar, z. B. über das Setzen der Werte in der newBuilder-Methode.

Sind solche Einschränkungen nicht vorhanden, könnte alternativ mit unterschiedlichen Konstruktoren gearbeitet werden, in welchen jeweils nur einige der Felder gesetzt werden können.

Spätestens bei komplexeren Objekten wird auffallen, dass diese Methode eher ungeeignet ist. Der klassische Weg ist es hier entsprechende Getter und Setter zum Abrufen und Setzen der Eigenschaften bereitzustellen:

public String getName() {
    return name;
}

public void setName(String name) {
    this.name = name;
}

public String getForename() {
    return forename;
}

public void setForename(String forename) {
    this.forename = forename;
}

public String getUsername() {
    return username;
}

public void setUsername(String username) {
    this.username = username;
}

Zwar können Getter und Setter auch über Annotationen, z. B. mithilfe der Bibliothek Lombok, vor dem Compile-Vorgang, generiert werden, allerdings hält der Autor nicht sonderlich viel von dieser Art von „Präprozessor-Magie“.

Hierbei werden unnötige Abhängigkeiten für doch recht simple Aufgaben, an das Projekt angehangen, welche wiederum bestimmte Funktionsweisen vor dem Entwickler verstecken. Vor allem, wenn der Entwickler nicht mit dem Projekt vertraut ist, kann dies das Verständnis erschweren.

Unter Nutzung der Setter kann ein Objekt nun feingranular mit den gewünschten Werten befüllt werden:

User user = new User();

user.setName("Mustermann");
user.setForename("Max");
user.setUsername("maxmustermann");

Soll z. B. der Vorname nicht gesetzt werden, so kann die entsprechende Zeile einfach weggelassen werden. Diese Nutzung bzw. Schreibweise wird manchmal unter dem Namen Method Sequencing zusammengefasst.

An dieser Stelle könnte stattdessen ein Builder genutzt werden. Bei diesem würde das Ganze wie folgt aussehen:

User user = User.Builder.newBuilder()
        .name("Mustermann")
        .forename("Max")
        .username("maxmustermann")
        .build();

Bei dieser Schreibweise wird der Builder genutzt, um das Objekt zu erstellen und mit seinen Werten zu befüllen. Der Builder liefert dazu die benötigen Methoden:

public static final class Builder {
    private String name;
    private String forename;
    private String username;

    private Builder() {
    }

    public static Builder newBuilder() {
        return new Builder();
    }

    public Builder name(String name) {
        this.name = name;
        return this;
    }

    public Builder forename(String forename) {
        this.forename = forename;
        return this;
    }

    public Builder username(String username) {
        this.username = username;
        return this;
    }

    public User build() {
        return new User(this);
    }
}

In vielen modernen Implementationen des Pattern wird meist auf das Präfix set für die Setter verzichtet und stattdessen nur der Name des Feldes als Methode definiert. Alternativ wird häufig auch das Präfix with genutzt.

Beim Quelltext wird ersichtlich, dass jede Methode, bis auf die build-Methode, eine Instanz des Builders zurückgibt und damit die Verkettung der unterschiedlichen Methoden erlaubt.

Fluent Interfaces zur Definition einer DSL nutzen

Neben dem Entwicklungsmuster des Builders können mithilfe von Fluent Interfaces domänenspezifische Sprachen (DSLs) erstellt werden.

Bei solchen Sprachen handelt es sich um speziell für ein bestimmtes Anwendungsgebiet entwickelte Programmiersprachen. Sie sind oft einfacher und leichter zu verstehen als allgemeine Programmiersprachen und ermöglichen es Entwicklern bzw. den Anwendern der Sprache, effizienter und präziser zu programmieren.

DSLs werden häufig in bestimmten Bereichen wie der Finanzbranche, der Medizin, der Luftfahrtindustrie, der Spieleentwicklung und der Datenanalyse eingesetzt. Sie können dazu beitragen, Prozesse zu automatisieren und zu vereinfachen und ermöglichen Entwicklern, komplexe Aufgaben in kürzerer Zeit zu erledigen.

Zu den bekanntesten domänenspezifischen Sprachen gehört SQL und auch reguläre Ausdrücke können als DSL gesehen werden. Grundsätzlich werden domänenspezifischen Sprachen in externe und interne Sprachen unterteilt.

Bei den internen DSLs wird eine Wirtssprache, in diesem Beispiel Java, genutzt, um die DSL abzubilden. Externe DSLs hingegen stehen für sich allein und nutzen keinerlei Wirtssprache. Deshalb sind sie auf eigens dafür entwickelte Compiler oder Interpreter angewiesen.

Im folgenden Beispiel soll eine DSL für HTML entwickelt und anhand dieser sollen einige Konzepte der sprechenden Schnittstellen in Zusammenhang gebracht werden. Die HTML-DSL soll dazu genutzt werden, HTML-Dokumente zu bauen. Ein Aufruf dieser DSL könnte wie folgt aussehen:

String html = new Html()
        .head()
          .meta("UTF-8")
          .meta("keywords", "fluent, interface")
          .title("Fluent interfaces")
          .finalise()
        .body()
          .text("Fluent interfaces")
          .br()
          .finalise()
        .generate();

Während bei einem einfachen Builder immer der Builder als solcher zurückgegeben wird, wird in diesem Fall nicht immer das Hauptobjekt, die Klasse Html, zurückgegeben. Stattdessen werden teilweise sogenannte Intermediate-Objekte zurückgegeben. Diese haben außerhalb der DSL keinerlei sinnvolle Funktionalität, sondern dienen dazu nur die Methoden anzubieten, welche im Kontext von HTML erlaubt sind.

Über Intermediate-Objekte lassen sich somit auch bestimmten Reihenfolgen erzwingen. Damit kann der Compiler zumindest zur partiellen Überprüfung der Anweisungen benutzt werden und dem Anwender bzw. Entwickler werden nur die Funktionalitäten zur Verfügung gestellt, welche im entsprechenden Kontext sinnvoll sind.

Über die Intermediate-Objekte werden die entsprechenden Methoden zur Verfügung gestellt

Unterstützt wird der Entwickler daneben durch die Autovervollständigung der IDE, welche die Methoden des jeweiligen Intermediate-Objektes darstellen kann. Anschließend dient die Methode finalise dazu, wieder eine Ebene höher in der Hierarchie der Intermediate-Objekte zu wandern.

In der Theorie könnten die entsprechende Verschachtelung beliebig komplex gestaltet werden. So können div-Blöcke als Elemente genutzt werden und innerhalb des Intermediate-Objektes für den div-Block stehen dann ausschließlich solche Elemente, welche im Rahmen eines div-Blockes genutzt werden können.

Bei der Nutzung einer solchen domänenspezifischen Sprache ist es wichtig, dass der jeweilige Aufruf auch sinnvoll beendet werden muss. So kann es bei falscher Nutzung durchaus passieren, dass der Entwickler, wenn er entsprechende Aufrufe vergisst, ein Intermediate-Objekt als Rückgabe am Ende erhält, mit welchem er nicht viel anfangen kann. Dieses Problem wird auch als Finishing-Problem bezeichnet.

Beim Design einer DSL muss immer sichergestellt werden, dass es einen Aufruf in den jeweiligen Intermediate-Objekten gibt, welcher dafür sorgt am Ende ein sinnvolles Ergebnis zu erhalten bzw. wieder zum eigentlichen Objekt zurückführt.

Automatische Generation von sprechenden Schnittstellen

Viele domänenspezifische Sprachen werden von Hand geschrieben, allerdings existieren durchaus Ansätze solche Sprachen auch über eine entsprechende definierte Grammatik zu generieren.

Auch Codegeneratoren wie z. B. für GraphQL-Schnittstellen erzeugen unter Umständen Fluent Interfaces, welche dann genutzt werden können:

return new ProductResponseProjection()
        .categoryId()
        .categoryName()
        .issuingCountry();

In diesem Fall wird aus dem GraphQL-Schema eine entsprechende API plus das dazugehörige Modell generiert, welches sich dann nach Außen hin als Builder– bzw. Fluent Interface darstellt.

Ob und wieweit die Generierung von sprechenden Schnittstellen automatisiert werden kann, hängt immer sehr stark vom jeweiligen Anwendungsfall ab.

Fazit

Fluent Interfaces sind ein Begriff, der nun schon eine Weile durch die Welt geistert und wahrscheinlich finden sich in den Köpfen unterschiedliche Vorstellung davon.

Teilweise ist es schwierig, eine harte Definition von sprechenden Schnittstellen zu finden, wie der StringBuilder unter Java zeigt:

String abc = new StringBuilder()
        .append("ABC")
        .append("DEF")
        .append("GHJ")
        .toString();

Die append-Methode stellt hier eine Art Builder-Pattern in Form einer sprechenden Schnittstelle zur Verfügung und kann damit im Kleinen als solche gesehen werden. Die Bandbreite von Fluent Interfaces im Kleinen, wie dem Builder-Pattern, bis zu ausgewachsenen domänenspezifischen Sprachen mit eigenen Grammatiken ist groß.

Alles in allem spielen sprechende Schnittstellen vorwiegend bei komplexen Objekten und entsprechenden Use Cases ihre Stärken aus. Sie sorgen für mehr Verständnis und nutzen die Möglichkeiten des Compilers und der IDE zur Unterstützung aus.

Trotz der Vorteile, welche solche sprechenden Schnittstellen bieten, sollte vor der Implementation immer genau überlegt werden, ob für den jeweiligen Anwendungszweck wirklich ein solche benötigt wird. Hier sollte die erhöhte Komplexität in der Implementation und Pflege mit der Notwendigkeit abgewogen werden.

Der Quellcode der einzelnen vorgestellten sprechenden Schnittstellen kann über GitHub eingesehen und ausprobiert werden.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.