Visuelle Komplexitätsmuster, die die Lesbarkeit von Code verschlechtern (2023)

• Bei der Durchsicht einer aktuellen Codebasis entstand trotz guter Codequalität ein mental ermüdendes Gefühl
  • Das hing weniger mit der Komplexität des Codes als mit seiner Lesbarkeit zusammen
• Es wurden acht Muster abgeleitet, um die Lesbarkeit von Code zu verbessern

Metriken für Codelesbarkeit und alternative Komplexitätsmetriken

• Es gibt keine allgemeingültige und weit verbreitet genutzte Metrik zur Messung der Lesbarkeit von Code
• Stattdessen existieren vor allem wissenschaftliche Arbeiten oder persönliche Meinungen, die in der Praxis kaum verwendet werden
• Anstatt neue Metriken zu entwickeln, liegt der Fokus auf visuellen Mustern, die jeder leicht diskutieren kann
• Wichtige Bedingungen für Komplexitätsmetriken:
  • Sie sollten auf Quellcode-Snippets oder einzelne Funktionen anwendbar sein
  • Der Fokus liegt auf der Art, wie Code geschrieben ist, nicht auf algorithmischer Komplexität
  • Stil-Elemente (Variablennamen, Leerraum, Einrückung usw.) stehen nicht im Fokus

Halstead-Komplexitätsmetriken

• Eine in den 1970er-Jahren von Maurice Halstead entwickelte Metrik für Codekomplexität
• Sie kann die Art, wie Code geschrieben ist, unabhängig von Sprache und Plattform quantifizieren
• Auf Basis der Anzahl von Operatoren und Operanden werden Länge, Volumen und Schwierigkeit eines Programms berechnet
• Wichtige Messwerte:
  • Anzahl eindeutiger Operatoren (n1)
  • Anzahl eindeutiger Operanden (n2)
  • Gesamtzahl der Operatoren (N1)
  • Gesamtzahl der Operanden (N2)
• Je mehr Operatoren und Operanden verwendet werden, desto höher ist die Komplexität des Codes
• Da Operatoren und Operanden nicht in jeder Sprache eindeutig definiert sind, ist der Einsatz konsistenter Tools wichtig

Erkenntnisse aus der Halstead-Komplexität

• Kurze Funktionen mit wenigen Variablen sind besser lesbar
• Sprachspezifische Operatoren oder syntactic sugar sollten nur sparsam eingesetzt werden
• Auch in der funktionalen Programmierung verschlechtern lange Chains (map/reduce/filter usw.) die Lesbarkeit

Kognitive Komplexität (Cognitive Complexity)

• Eine von SonarSource entwickelte Komplexitätsmetrik
• Ein Versuch, die Schwierigkeit des Codeverständnisses genauer zu messen
• Drei zentrale Prinzipien:
  1. Kurzschreibweisen (shorthand constructs) verringern die Leseschwierigkeit
  2. Unterbrechungen des nichtlinearen Kontrollflusses erhöhen die Schwierigkeit
  3. Verschachtelte Kontrollflüsse erhöhen die Schwierigkeit

Erkenntnisse aus der kognitiven Komplexität

• Kurzschreibweisen sind kompakt, bergen aber ein potenzielles Bug-Risiko
• Bedingungen und logische Operatoren verschlechtern bei übermäßigem Einsatz die Lesbarkeit
• Exception Handling ist ein wesentlicher Treiber von Codekomplexität
• goto sollte im Allgemeinen vermieden werden, kann aber in bestimmten Situationen nützlich sein
• Verschachtelte Kontrollstrukturen sollten möglichst reduziert werden

Form, Muster und Variablen in Funktionen

• Die visuelle „Form“ einer Funktion spielt eine wichtige Rolle für die Lesbarkeit von Code
• Drei Prinzipien für bessere Lesbarkeit:
  1. Klare und spezifische Variablennamen verwenden
  • Shadowing von Variablen vermeiden
  • Visuell gut unterscheidbare Namen verwenden (i, j und ähnliche Namen vermeiden)
  2. Die Lebensdauer von Variablen verkürzen (liveness)
  • Je kürzer der Gültigkeitsbereich einer Variablen, desto besser
  • Variablen, die lange über Funktionsgrenzen hinweg bestehen bleiben, erhöhen die Komplexität
  3. Vertraute Code-Muster wiederverwenden
  • Konsistente Code-Muster verbessern die Lesbarkeit
  • Vertraute bestehende Muster sollten neuen Ansätzen vorgezogen werden

Acht Muster zur Verbesserung der Codelesbarkeit

1. Anzahl von Zeilen/Operatoren/Operanden verringern – kleine Funktionen und wenige Variablen verbessern die Lesbarkeit
2. Neue Herangehensweisen vermeiden – vertraute Muster in der Codebasis beibehalten
3. Gruppierung – lange Funktions-Chains, Iteratoren usw. in Hilfsfunktionen auslagern
4. Bedingungen vereinfachen – Bedingungen kurz halten und die Mischung logischer Operatoren minimieren
5. goto minimieren – wenn nötig, nur eingeschränkt für Error Handling verwenden
6. Verschachtelung minimieren – verschachtelte Logik reduzieren und bei Bedarf in Funktionen auslagern
7. Klare Variablennamen verwenden – spezifische und nicht doppeldeutige Variablennamen nutzen
8. Lebensdauer von Variablen verkürzen – sie innerhalb der Funktion kurz halten und nicht über Funktionsgrenzen hinausreichen lassen

Fazit

• Codelesbarkeit ist ein wichtiger Faktor für Codequalität
• Halstead und Cognitive Complexity können Lesbarkeitsprobleme quantifizieren und Verbesserungsrichtungen aufzeigen
• Prägnanter und klarer Code erleichtert die Wartung und verringert die Wahrscheinlichkeit von Bugs
• Gute Codeerstellung priorisiert Einfachheit, Konsistenz und Klarheit

[GN⁺]

Hacker-News-Kommentare

• Das Verketten funktionaler Programmierkonstrukte wie map, reduce und filter ist kompakt, aber lange Ketten neigen dazu, die Lesbarkeit zu verschlechtern

  • Das ist nicht das, was der Artikel impliziert
  • Es wirkt wie eine allgemeine Beschwerde der Art, etwas sei schlecht, nur weil man nicht damit vertraut ist
  • Wenn man sich ein wenig daran gewöhnt hat, ist es leichter zu lesen und zu schreiben als andere Methoden
  • Es ist wichtig, die Grundlagen der funktionalen Programmierung zu lernen
  • Man muss Monaden nicht erklären, sollte aber zumindest genug Vertrautheit haben, um nicht wahllos auf map und filter zu schimpfen

• Ein wichtiger Aspekt von gutem Code ist qualitativ und literarisch

  • Das kann für Programmierer und Akademiker mit mathematischer Denkweise unangenehm sein
  • Ich mag Dostojewski und Wodehouse, aber ihr Schreiben ist sehr unterschiedlich
  • Es dauert eine Weile, den Stil einer Codebasis zu verstehen

• Das ermüdendste Problem beim Lesen von Code ist Veränderlichkeit

  • Die Fähigkeit, eine Variable nur einmal zu „fixieren“, ist ein großes Geschenk
  • Der Prozess, eine Methode zu verstehen, sollte monoton von 0 % auf 100 % ansteigen
  • GOTOs sind deshalb schädlich, weil es schwierig ist, den Zustand veränderlicher Variablen zu kennen

• Kleine Funktionen und wenige Variablen sind im Allgemeinen leichter zu lesen

  • Der Fokus auf „Lesbarkeit“ ist auf Mikro-Lesbarkeit verzerrt
  • Das führt dazu, dass Code übermäßig fragmentiert wird
  • Sprachen aus der APL-Familie stehen am entgegengesetzten Extrem

• TypeScript macht Code schwerer lesbar

  • Wenn das Datenmodell „atomar“ bleibt, ist das in Ordnung
  • Wenn man sich auf Typinferenz verlässt, ist es schwer, Felder bis zu ihrem ursprünglichen Ort zurückzuverfolgen

• Die Funktion getOddness4 erzeugt Asymmetrie

  • Die Funktion getOddness2 bietet eine symmetrische Auswahl

• Der Artikel ist interessant, aber nicht zufriedenstellend

  • Ich stimme der Ansicht nicht zu, dass man die Verwendung sprachspezifischer Operatoren oder syntaktischen Zuckers vermeiden sollte
  • Konstrukte wie map, reduce und filter ersetzen bei guter Verwendung andere Operatoren und reduzieren das „Volumen“

• Der Versuch, Lesbarkeit zu definieren, ist lobenswert

  • Mit Tests an vielen Menschen könnte man die tatsächlichen Dimensionen von Lesbarkeit herausfinden

• Codekomplexität wird durch die Größe des Syntaxbaums ausgedrückt

  • Eine Verringerung lokaler Komplexität hat keinen großen Einfluss auf die Gesamtkomplexität

• Lange Funktionsketten oder Callbacks sollte man in kleine Gruppen aufteilen und gut benannte Variablen verwenden

  • Beide Versionen sind hinsichtlich der Effizienz gleich
  • Der Unterschied liegt im Compiler