Große JS-Dateien

[fischlak]

Hallo encoder,

die Fragen, die Du stellst ("Was machst du, wenn du...?"), sind aus Deinem Paradigma formuliert. In meinem Paradigma sind sie teilweise schon beantwortet.

• "Wiederholung überall?": Ich wiederhole nicht blind, ich kapsele lokal, wo Wiederverwendung (oder potenzielle künftige Wiederverwendbarkeit) keinen Mehrwert bringt.

• "Was, wenn du was korrigieren musst?": Ich bin nicht gegen Wiederverwendung – wie sollte das denn funktionieren? Ich bin aber gegen dogmatische Zentralisierung.

• "Geschachtelte Funktionen als Bremse?": Für Dich: ja, weil Du nicht so arbeitest wie ich. Für mich: nein, weil ich in Chunks und Folding-Einheiten denke.

Findest du das Geschachtel von Funktionen tatsächlich übersichtlich?

Ich kann Dich gut verstehen. Denn wenn ich mein gefoldetes Skript mal mit einem anderen Editor öffne, also einem Editor, der mir die Folding-Struktur nicht anzeigt, dann sehe ich ein riesengroßes Chaos voller verschachtelter Unübersichtlichkeiten. Unmöglich, da noch klarzukommen. Und genau DAS hast Du in Deinem gedanklichen Visier! Du berücksichtigst nicht, dass bei einer Sichtung mit persistentem Folding sich eine ganz andere visuelle Struktur ergibt, weil Du es noch nie gesehen hast und nicht gewöhnt bist.

Du siehst Chaos, weil Du die Folding-Struktur nicht berücksichtigst.

Ungefaltet sieht mein Code so aus:

• verschachtelte Funktionen

• viele IIFEs

• lokale Blöcke

• Inline‑Hilfsfunktionen "mitten drin""

• viele Ebenen

• scheinbares Durcheinander

Gefaltet:

• klare Chunks

• sprechende Blocknamen

• kompakte Übersicht

• semantische Nähe

• visuelle Ruhe

• viel weniger Scrollen

• bessere Orientierung

Du siehst nur die erste Version, also "ungefoldet", weil Du aus der Perspektive Deines Paradigmas betrachtest. Deshalb wirkt mein Stil auf Dich chaotisch.

Natürlich kann ich bei wiederverwertbarem Code keine Lokalität herstellen.

In meinem aktuellen Projekt schätze ich den Anteil wiederverwertbaren Codes auf um die 60% bis 70%. Einen Teil dieser wiederverwertbaren Funktionen kann ich zwar "in der Nähe" halten, aber sie sind nicht mehr "visuell lokal".

D.h. bei etwa 50 % allen Codes kann ich keine lokale Nähe herstellen. Btw: Genau in solchen Fällen kann das Peek-Feature (VSCodium u.a.) die visuelle Distanz zumindest einigermaßen entschärfen.

Aber die anderen 50% erhöhen durch ihre lokale Nähe die Lesbarkeit. Und 30% bis 40 % sind tatsächlich visuell lokal, sodass sich beim Sichten der Zusammenhänge innerhalb dieser lokalen Funktionen weniger mentale Last ergibt.

An vielen Stellen habe ich Codezeilen, die hintereinanderweg geschrieben sind und im Zusammenhang einmalig sind. Es ist ja nicht so, dass ein komplettes Skript ausschließlich aus wiederverwertbarem Code besteht, wo ich die extern gehaltenen Bausteine nun wiederverwende. Es bleiben genügend Abschnitte übrig mit individuell an das aktuelle Projekt zugeschnittenen Codezeilen.

Ein Beispiel: Wenn ich während des Codens einen semantisch zusammenhängenden Block erkenne, also einen Code-Abschnitt voller hinereinanderweg geschriebener einmalig verwendeter Code-Zeilen, die aber einen semantischen Zusammenhang bilden, dann mach ich eine IIFE daraus, sodass der Block zu einer Funktion wird, dann also ohne eine explizite Referenz ausgeführt wird, gebe dieser IIFE einen sprechenden Namen und klappe sie dann ein.

Auf diese Weise kann ich meinen Code visuell verkleinern, ohne jedoch die Übersicht zu verlieren, sondern im Gegenteil: Ich reduziere Chunks, scrolle weniger, weiß aber trotzdem, was im Code passiert. Das mach ich sogar inline in Schleifen. Und nur aus einem einzigen Grund: Um bessere Übersicht zu bekommen.

Sowas geht nicht immer – aber es geht oft.

Die meisten Entwickler strukturieren Code nach Paradigmen:

• OOP -> Methoden oben

• FP -> pure functions oben

• "Best Practices" -> alles schön sortiert in Module

Ich versuche, Code nach mentaler Ergonomie zu strukturieren:

• Nähe

• Chunk‑Größe

• visuelle Ruhe

• lokale Semantik

Das ist ein anderes Optimierungsziel. Ich optimiere nicht für Paradigmen. Ich versuche, für kognitive Effizienz zu optimieren.

Mein Stil ist so ungewöhnlich, weil fast niemand so bewusst über "visuelle Strukturierung" nachdenkt. Ich versuche, visuelle Komplexität und Kontextwechsel zu reduzieren, indem ich semantische Nähe erhöhe. Also eine Art "UX‑Design für Code".

Mein Stil ist nicht Mainstream – aber er funktioniert. Und das ist der entscheidende Punkt. Wenn ein Stil konsistent ist, Fehler vermeidet, Übersicht schafft, mentale Last reduziert, produktiv macht, – dann ist es doch OK. Egal, ob er "üblich" ist oder nicht.

Ja, mein Ansatz, Code als "mentales UX-Design" zu betrachten, ist ungewöhnlich. Ich versuche im Grunde "Spatial Locality" für die menschliche Aufmerksamkeit. Dass ich Inline-Funktionen, IIFEs und Folding als Werkzeuge nutze, um die "Sichtweite" künstlich zu begrenzen (und damit die mentale Last zu senken), ist natürlich ein Argument gegen das Dogma der absoluten Zentralisierung.

Und dass mein Konzept "UX-Design für Code", innerhalb einer Entwickler-Community formuliert, eine Debatte auslösen würde, wundert mich nicht. Während klassisches Software-Design meistens technische Metriken optimiert (Wiederverwendbarkeit, Entkoppelung, Testbarkeit), versuche ich, die Schnittstelle zwischen Code und Bewusstsein zu optimieren.

Gruß, fischlak