In unserem letzten Blog-Beitrag haben wir gesehen, wie hilfreich unions im Alltag jedes Programmierers sein können und dass unions vollkommen zu Unrecht einen schlechten Ruf in Applikationscode haben.

Code-Bloat durch Spracheigenschaften⌗

So mancher C++-Programmierer blickt neidisch auf seine IT-Kollegen, die sich nicht mit Type-Safety und anderen nutzlosen Einschränkungen herumschlagen müssen, die ihnen durch die Sprache C++ auferlegt wird. Vermeintlich, wie wir sehen werden. Die Kollegen ohne diese Einschränkungen nutzen Perl, PHP, Python, JavaScript und werden bei ihrer Arbeit im Lösungsraum weit weniger behindert als jeder C++-Programmierer.

Der Schmerz wurde erkannt⌗

Die meisten gängigen Programmiersprachen kennen mittlerweile Abkürzungen in den Variablendeklarationen, wenn der Typ ohnehin feststeht. Wenn das MyType t = new MyType() ohnehin den Typ explizit benennt, warum sollte man dann noch den Typ komplett benennen müssen?

JavaScript, PHP, Perl und viele andere Sprachen weisen hier seit jeher eine großartige Unterstützung auf. Eventuelle Typanpassungen passieren in diesen Sprachen, ohne dass der Programmierer darum kümmern muss.

Jüngere Sprachen wie Dart oder C# haben die Abkürzung var im petto, die dem Entwickler genau die lästige Arbeit erspart, die keinen zusätzlichen Wert erzeugt, sondern nur die Code-Menge anwachsen lässt.

Hier ein einfaches Beispiel:

In einer medizinischen Applikation haben wir folgendes Konstrukt in einer for()-Schleife gefunden:

std:list<std:array_map<std:list<atd:array_map<std:string,std:string>,std:string>,std:list<int,std:string>>> thisPatient =
(std:list<std:array_map<std:list<atd:array_map<std:string,std:string>,std:string>,std:list<int,std:string>>>) getDataForPatient(patientName);

Solche Ausdrücke sind nicht nur unverständlich, sondern enthalten keine zusätzlichen für den Menschen nützlichen Informationen. Der Code braucht eine Entrümpelung.

Sprachökonomie⌗

Programmiersprachen sind im Kontext der Weltgeschichte der Sprachen bestenfalls frisch geboren, wenn nicht sogar noch im Kreissaal. In der Linguistik haben sich seit vielen Jahrhunderten evolutionär zwei Konzepte durchgesetzt:

Verringerung des Signal-to-Noise-Ratio⌗

Informationen sollten nur die nötigen Signale enthalten, die die Nachricht für ihr Verständnis beim Empfänger benötigt. Übersetzt auf Code bedeutet das: Weg mit dem syntaktischen Quatsch, mehr Platz für die relevanten Informationen.

Konventionen und inhärentes Wissen⌗

Sofern für das Verständnis eines Kommunikationskontext wiederkehrend viel Hintergrundinformation benötigt wird, soll diese als Sprachkonvention etabliert werden. In der Realität erleben wir dies als Schulterzucken, Kopfschütteln, Sprichwörtern und Floskeln. Genau das könnten wir auch in Programmiersprachen gut gebrauchen.

Die Lösungen⌗

In C# oder Flutter haben sich die dynamischen Typen mit dem Schlüsselwort dynamic oder var als state-of-längst etabliert. Mit derart kurzen Typnamen bleibt die Intention des Codes deutlich sichtbar. Seit C++11 kennt C++ das Schlüsselwort auto, das selbst aber statisch getypt ist und daher nur einen Teil des Wahnsinns erschlägt.

Die Magie des void*⌗

Mit void* bringen C und C++ einen Ausweg aus dieser Misere. Void* ist explizit dafür gemacht worden, beliebige Objekte zu referenzieren. Dies wurde auch in Zahlreichen APIs seit Jahrzehnten so gehandhabt. Da es sich bei einem Pointer um eine Adress-Variable handelt, kann auch ohne Weiteres eine Zahl zugewiesen werden.

void* myVar = (void*)"hello";
myVar = (void*)1234;
myVar = (void*)false;

Doch leider stören die vielen Casts die Lesbarkeit. Wir nutzen ein #define, um diesem Aspekt weniger Sichtbarkeit zu geben:

#define _ void*
#define _. (_)

Nach dieser kleinen Änderung ist unser Code endlich deutlich lesbar und auf den Punkt.

_ myVar = _."hello";
myVar = _.1234;
myVar = _.false;

Fazit⌗

Entwickler heute brauchen den vollen Lösungsraum, bei gleichzeitig guter Lesbarkeit. Viel zu oft haben Entwickler sich in der Vergangenheit mit länglichen Type-Konstrukten herumgeschlagen. Leicht lesbarer Code? C++ war schon immer bereit dafür!