Code-Highlighting nach Maß: Was wirklich zählt
Highlighting My Code Based on How Much I Care
Der Autor hinterfragt die gängige Syntaxhervorhebung und entwickelt ein eigenes, minimalistisches Farbschema. Ausgangspunkt ist die These, dass zu viele Farben die Aufmerksamkeit verwässern. Er experimentiert mit Graustufen und priorisiert Elemente nach ihrer Bedeutung: Kommentare, Definitionen und Kontrollfluss heben sich hervor, während Schlüsselwörter und Satzzeichen zurücktreten. Das Ergebnis ist ein System, das die Lesbarkeit von Code durch gezielte Kontraste verbessert – ganz ohne bunte Ablenkung.
Wenn ich nicht weiß, welche Farbe meine Klassen in meinem Farbschema haben, dann ist mein Farbschema nicht funktional.
- nrabulinski
> Versuch dich zu erinnern, welche Farbe dein Farbschema für Klassennamen verwendet?
Obwohl ich dem Punkt dieses Beitrags und des zitierten Beitrags insgesamt zustimme, bin ich nicht mit der Prämisse einverstanden, dass man in der Lage sein muss, sich Fakten wie diese aktiv ins Gedächtnis zu rufen. Das Thema, das ich persönlich verwende, ist ziemlich dezent, aber es verwendet verschiedene Farben für Variablen, Schlüsselwörter, Argumente, Typnamen und einige andere Klassen von Tokens. Ich denke nicht bewusst "hmm, welche Farbe hat ein Argument", um danach in meinem Code zu suchen - ich sehe sie einfach, habe sie über die Jahre gelernt, und es ist inzwischen Muskelgedächtnis, und es hilft mir, den Code zu lesen. Genauso wie ich mir den Code zu meinem Wohngebäude nicht merken kann, obwohl ich ihn mehrmals täglich eingebe.
- sph
Ich bin überzeugt, dass jeder Syntax-Highlighting falsch macht, und dieser Artikel bestätigt mich.
Meine Steckenpferde:
- Ich habe keine Ahnung, wie Leute mit nicht-semantischen Regenbogen-Erbrochenes-Themen produktiv sein sollen, die in modernen Editoren so beliebt sind. Ich bin zu ADHS, um von nutzlosen Informationen übermäßig stimuliert zu werden.
- Ich hasse es regelmäßig, Zig-Code auf Github zu sehen, wo das verwendete Theme alles braun macht. Oh, es ist, weil es ein Struct-Member ist. Alter, in Zig ist alles ein Struct-Member, es ist albern, eine lebendige Farbe für das zu reservieren, was 90% des Quellcodes ausmacht. Zufälliges Beispiel aus meinem Browserverlauf: https://github.com/foxnne/aftersun/blob/main/src/time/enviro...
- Gestern habe ich etwas Lisp-Code im KDE KWrite-Texteditor geöffnet, und jedes einzelne Standard-Theme hebt Klammern mit einer fetten Schrift und einer lebendigen Farbe hervor, um sie hervorzuheben. Klammern in Lisp sollen im Hintergrund verschwinden, nicht ins Gesicht springen. Es war völlig unbrauchbar, ich musste Syntax-Highlighting ausschalten.
Ich bin immer auf der Suche nach guten, minimalistischen, gedeckten Farbschemata für meine Editoren. Ich wünschte, wir hätten ernsthafte Designer, die Themes für Benutzerfreundlichkeit und Komfort entwerfen, und nicht Leute, die nichts mit Farben zu tun haben sollten.
Ich erinnere mich an einen Kollegen, der Code ohne Syntax-Highlighting schrieb, und dachte, das wäre eine exzentrische Wahl. Je älter ich werde, desto mehr schätze ich seine Weisheit. Ich hätte lieber kein Syntax-Highlighting als ein schlechtes; zumindest würde man versuchen, den Code allein durch seine Struktur leicht zu parsen (kurz [...]
- wzdd
Diese Beiträge zum Überdenken von Highlighting beginnen immer mit der falschen Prämisse. Die Farbe für Klassennamen in meinem Code ist die Farbe, die alle Klassennamen haben. Nach kurzer Zeit mit dem Code würde mir auffallen, wenn einer falsch aussieht.
Das Gehirn ist wirklich sehr effizient. Man optimiert nicht auf zufälliges Abrufen aus dem Kontext, es sei denn, man bemüht sich wirklich sehr. Es sagt nichts über die Wirksamkeit des Schemas aus.
- mattlondon
Hmm, das war nicht ganz das, was ich erwartet hatte.
Ich dachte, das wäre vielleicht eine Art Hervorhebung basierend auf Komplexität/Risiko/Wichtigkeit. Das schien mir sofort ein "Warum bin ich da nicht drauf gekommen?!"-Moment zu sein, wenn sich tatsächlich herausstellt, dass sie es auch nicht taten.
Ich kann mir also ein Szenario vorstellen, in dem man einen Diff eines LLM-Agenten zur Überprüfung hat, während man in einer IDE iteriert. Der Diff würde nach Wichtigkeit/Komplexität für die menschliche Überprüfung hervorgehoben. Trivialitäten wie Getter und Setter wären grau. Hochkomplexer oder komplizierter oder riskanter Code würde in einer kontrastreichen fetten Farbe hervorgehoben (vielleicht mit einer Luminanzskala, je nachdem, wie kritisch er war). Wenn man dann den Diff vom Agenten überprüft, kann man sofort die wichtigsten Teile sehen und sich darauf konzentrieren, die die meiste Aufmerksamkeit benötigen.
Ich fände das wirklich nützlich.
- FridgeSeal
Ich könnte dir nicht sagen, welche Farbe meine Funktions- oder Struktursyntax hat, aber ich kann dir sagen, dass mich beim Anblick von Code das Vorhandensein der Farbe sofort zu dem Teil des Textes führt, der mich in dem Moment interessiert.