Softwareentwickler haben eine merkwürdige Beziehung zu Regelwerken. Einerseits ist Programmcode quasi ein riesiger Haufen von Regeln, der von pflichtbewussten maschinellen Gatekeepern immer und immer wieder durchgesetzt wird. Allerdings gibt es da noch einen anderen Layer von Regeln, die weniger sakrosankt, sondern vielmehr äußerst flexibel sind: die Regeln, die Entwickler an sich selbst anlegen, beziehungsweise an das, was sie tun.

Wobei es per se nichts Schlechtes ist, mit bewährten Regeln auch einmal zu brechen. Zum Beispiel, wenn letztere hoffnungslos veraltet oder von vorneherein unausgegoren sind. Manche vermeintliche Unsitte kann dabei unter Umständen auch zum Vorteil gereichen. Zum Beispiel die folgenden neun.

1. Kommentarloser Code

Dass undokumentierter Code ein Alptraum ist, wenn man ihn verstehen will oder Fehler sucht, ist bekannt. Darum wird auch in jedem Dev-Seminar beständig vermittelt, dass sinnvolle Code-Kommentare unerlässlich sind. Der Programmierstil des "Literate Programming" kombiniert sogar Code und natürliche Sprache - und wurde von Don Knuth erfunden, einem der größten Developer überhaupt.

Die traurige Wahrheit: Manchmal machen Code-Kommentare alles nur noch schlimmer. Zum Beispiel, wenn der Eindruck entsteht, dass Programmcode und Dokumentation nur rudimentär etwas miteinander zu tun haben. Eventuell hat ein Programmierer auch einen kritischen Patch eingefügt und vergessen, das Dokumentations-Team darüber zu informieren. Vielleicht weiß letzteres auch darum, konnte sich aber bislang noch nicht dazu durchringen, die Kommentare zu aktualisieren. Im Alltag kommen viele weitere Probleme hinzu, beispielsweise, wenn Kommentare in Fremdsprachen verfasst oder schlicht nicht korrekt sind.

Im Umkehrschluss gehen einige Entwickler davon aus, dass das beste Mittel gegen nutzlose Kommentare sei, diese möglichst spärlich zu verwenden - oder gar nicht. Stattdessen ziehen diese Devs es vor, einfache, kürzere Funktionen zu schreiben, die längere, beschreibende Variablennamen verwenden.

2. Langsamer Code

Wenn Sie schnellen Code wollen, gestalten Sie ihn einfach. Wenn er wirklich schnell sein soll, komplex. Mit Blick auf diesen Task den richtigen "Sweet Spot" zu finden, ist gar nicht so einfach.

Wie so oft gilt es, einen Kompromiss zu finden: Ganz allgemein sollen Programme möglichst schnell sein. Dabei kann Komplexität ein wesentliches Hindernis darstellen, wenn diese niemand mehr durchdringen kann. Wenn es also nicht unbedingt auf Speed ankommt, kann es durchaus sinnvoll sein, etwas langsameren, dafür aber leicht verständlichen Programmcode zu schreiben.

3. Code-Mode

Manche Entwickler haben eine ausgeprägte Vorliebe für Dinge wie die neuen Operatoren in JavaScript (etwa die Ellipsis), weil der resultierende Code in ihren Augen prägnanter und damit besser ist. Ob das aber auch in jedem Fall leichter zu verstehen ist, darf bezweifelt werden. Das erfordert nämlich erst einmal, sich mit diesen Operatoren vertraut zu machen. Statt also den Code schnell und gründlich überfliegen zu können, wird daraus eine lästige, einnehmende Pflicht.

Es gibt auch historische Belege dafür, dass prägnanterer Code nicht unbedingt populär ist. Nicht umsonst sind Sprachen wie APL, die dank benutzerdefinierter Symbolik besonders effizient und prägnant sein sollte, im Wesentlichen verschwunden. Sprachen wie Python, die auf geschweifte Klammern vollständig verzichten, erfreuen sich hingegen zunehmender Beliebtheit.

4. Abstraktionen

Clevere Abstraktionen, die spezifische Probleme schneller lösen, sind in vielen Programmiersprachen gang und gäbe. Manche Sprachen sind dabei dermaßen mit Abstraktionen überfrachtet, dass ihre Handbücher im Resultat mehr als tausend Seiten füllen. Diese Funktionen wann immer möglich zu verwenden, ist in den Augen mancher Gesetz. Das Problem in der Praxis ist allerdings, dass zu viele Funktionen schnell Verwirrung stiften können. Und inzwischen existieren so viele syntaktische Kniffe, dass sie kein Dev der Welt mehr alle beherrschen kann. Und warum sollte man das auch? Wie viele Möglichkeiten brauchen wir, um auf Nullwerte zu testen oder Inheritance in mehreren Dimensionen zu ermöglichen?

Es gibt jedoch auch Gegenbewegungen: Die Schöpfer von Go haben sich etwa zum Ziel gesetzt, eine Sprache zu entwickeln, die in erster Linie besonders schnell zu erlernen ist. Die Grundvoraussetzung dafür: Alle im Team mussten in der Lage sein, den gesamten Code zu lesen und zu verstehen.

5. DIY-Code

Effizienzexperten empfehlen gerne, das Rad nicht neu zu erfinden, sondern sich auf bewährte Bibliotheken und Legacy-Code zu verlassen. In manchen Fällen kann ein neuer Ansatz jedoch durchaus sinnvoll sein. Schließlich sind Standard-Bibliotheken im Regelfall für alltägliche Use Cases gemacht. Bei spezifischen Anwendungsfällen, in denen diese Bibliotheken eher einen Flaschenhals darstellen, können schon ein paar individuelle Code-Zeilen respektive Ersatzfunktionen dafür sorgen, dass alles deutlich schneller abläuft.

Natürlich gibt es aber auch Fälle, in denen das gefährlich sein kann: Bei besonders komplexem Code - beispielsweise kryptografischen Systemen - ist es keine gute Idee, selbst zu Werke zu gehen, selbst wenn man alle mathematischen Grundlagen beherrscht.

6. Frühoptimierung

Dass Developer Code zusammenwerfen und das mit der alten Maxime rechtfertigen, verfrühte Optimierung wäre nur Zeitverschwendung, kommt relativ häufig vor. Der Gedanke der dahintersteht: Solange das ganze System nicht läuft, weiß niemand, welcher Teil des Codes am Ende zum Bottleneck wird.

Im Allgemeinen ist das eine gute Faustregel. Schließlich scheitern manche Softwareprojekte schon früh, weil sie überoptimiert wurden. Es gibt auf der anderen Seite aber auch diverse Fälle, in denen eine gesunde Voraussicht den Unterschied macht. Zum Beispiel, wenn falsche Datenstrukturen oder -schemata in eine Architektur münden, die nachträglich nicht so ohne Weiteres optimiert werden kann.

7. Sorgfalt

Gute Programmierer sichern Daten immer doppelt ab und überprüfen lieber dreifach, was vor sich geht - es könnte sich schließlich ein Null Pointer eingeschlichen haben. Leider kann diese zusätzliche Sorgfalt den Code aber auch lähmen. Deshalb ist es manchmal nötig, einfach mal loszulassen und auf Performance zu coden. Dazu beschränkt man sich dann eben auf das absolute Minimum.

8. Inkonsistenzen

Menschen stehen im Allgemeinen auf Ordnung. So auch Programmierer, die oft darauf bestehen, dass innerhalb eines Code-Haufens stets dieselben Techniken, Algorithmen und Syntax-Konstrukte zur Anwendung kommen. Das macht das Leben für alle Entwickler einfacher, die später einmal mit dem Code umgehen und ihn verstehen müssen. Andererseits kostet Konsistenz Zeit - und schafft manchmal auch zusätzliche Komplexität. Dabei ist nicht nur ein Problem, dass Code, der nicht den Vorgaben entspricht, unter Umständen komplett neu geschrieben werden muss: Einige Projekte stützen sich auf Legacy-Code, andere auf Bibliotheken. Viele kommen nicht ohne APIs aus, die wiederum von unterschiedlichen Unternehmen stammen.

Vollständige Konsistenz ist darüber hinaus oft nicht zu erreichen - und die Gelegenheit, den gesamten Stack neu aufzusetzen, um ihn an die aktuelle Vision anzupassen, dürfte sich nicht so oft bieten. Auch wenn es schwer fällt: Manchmal ist es sinnvoller, sich mit Inkonsistenzen abzufinden. Ein weiteres Problem bei zu viel Konsistenz: Innovationen können behindert werden. Schließlich fördert sie auf ihre eigene Weise, an einer alten Art, die Dinge zu erledigen, festzuhalten.

9. Regelverstöße

Spaßeshalber haben wir Googles Gemini gefragt, ob die Programmierer bei seiner Erstellung Regeln gebrochen haben. Seine Antwort: "Es ist nicht so, dass die Programmierer bestimmte Regeln gebrochen haben, sondern eher so, dass sie die Grenzen einiger bewährter Verfahren überschritten haben."

Selbst LLMs wissen also: Auch Regeln unterliegen manchmal dem Change. Developer sollten das ebenfalls verinnerlichen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.