Linearer Code ist besser lesbar

• Ein Artikel, der die im Google Testing Blog vertretene Sichtweise infrage stellt und die Lesbarkeit linearen Codes diskutiert
• Der Autor stimmt der Behauptung aus dem Google Testing Blog nicht zu, dass Funktionen mit getrennten Abstraktionsebenen besser lesbar seien
• Er argumentiert, dass linearer Code, der sich von oben nach unten lesen lässt, intuitiver und leichter zu verstehen ist als Code, der zwischen verschiedenen Abstraktionsebenen hin- und herspringt
• Zur Veranschaulichung nutzt der Autor das Beispiel einer Funktion zum Pizzabacken und wirft die Frage auf, ob diese Funktion den Ofen selbst aufheizt oder ob der Ofen vorher vorgeheizt werden muss
• Er schlägt vor, dass die Lesbarkeit von Code nicht durch eine Struktur entsteht, die Abstraktionsebenen trennt, sondern dadurch, dass klar erklärt wird, was die einzelnen Teile des Codes tun
• Der Autor spricht sich gegen das Extrahieren kleiner Funktionen aus linearem Code aus, insbesondere wenn sie nur einmal verwendet werden, da der Nutzen den Verlust an Linearität nicht aufwiegt
• Außerdem weist er auf ein mögliches Problem in Zusammenhang mit der Pizza-Funktion hin und fragt, warum jedes Mal ein neuer Ofen erzeugt wird, wenn eine Pizza gemacht wird, was in echtem Code zu Performance-Problemen führen könnte
• Er schlägt vor, dass der Ofen ein Parameter der Funktion sein sollte, dessen Bereitstellung in der Verantwortung des Aufrufers liegt, und dass die Funktion statt einer Pizza eine Box zurückgeben sollte

[GN⁺]

Hacker-News-Kommentare

• Die Lesbarkeit von linearem und modularem Code ist eine Stilfrage und erfordert gutes Urteilsvermögen und Gespür.
• Übermäßige Abstraktion kann zu einer frühen Kopplung des Codes führen.
• Das Extrahieren von Funktionen, um Arbeitseinheiten zu abstrahieren, kann einen Algorithmus ordnen, sollte aber mit Bedacht eingesetzt werden.
• Der bereitgestellte Beispielcode ist einfach und wenig skalierbar. Auch Wiederverwendbarkeit und Testbarkeit auf Unit-Ebene sollten berücksichtigt werden.
• Übermäßiges Refactoring kann die Wartung erschweren, weil dadurch andere Teile des Codes verschoben werden müssen.
• Linearer Code ist leicht zu lesen, weil er der Ausführungsreihenfolge folgt, skaliert aber in großen Codebasen schlecht.
• Knapp gehaltene Funktionen mit tief verschachtelten Call Stacks können in großen Codebasen zum Albtraum werden.
• Guter linearer Code ist leichter zu lesen, aber schwieriger zu warten und zu testen.
• Es ist eine gute Praxis, Funktionen möglichst klein und nahe an einem einzelnen Zweck zu halten.
• Die Struktur des Codes sollte an den Business-Anwendungsfällen ausgerichtet sein, damit er sich leicht verschieben lässt.
• Sowohl linearer als auch modularer Code lässt sich linear lesen, aber die Reihenfolge der Funktionen kann die Lesbarkeit beeinflussen.
• Echter Code ist oft komplexer und benötigt einen Überblick auf höherer Ebene, damit sich Leser nicht in Details verlieren.