Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Cool article, really cool website (the font could also be a bit smaller, if it didn't mess with the fidelity), but the grayscale setup just doesn’t have enough contrast for my eyes to reliably pick up on it at a glance.by KronisLV
- Blue
Yes
I think much of the usefulness of syntax highlighting is a matter of having gotten used to a specific editor. Long time Visual Studio user, I tried VSCode and Jetbrains but for C# I switched back to good old VS. I know the pattern, the cadence, by now. Much like QWERTY keyboards, I'm not learning DVORAK now, my workflow is fine this way. Tried F#, but I'm sticking with C#. It's not that I believe the rational arguments don't hold up, I do see possibilities for productivity gain with each. But there's the retraining curve and that also factors in for me
- I like the styling of the blog, but the font is actually very hard on the eyes.by rfgplk
- If rule-based highlighting of syntax is meaningfully helpful for reading code then how come nobody uses rule-based syntax highlighting of prose?
Why don't we visually emphasize the verb in a sentence and deemphasize articles and prepositions, for example?
In prose the author can *bold* or italicize text to emphasize ad-hoc, or make ## headings for scanning. Why can't we do such ad-hoc emphases in code?
by twitchard - one time i made a nlp-based syntax highlighter for english ebooks, and it was pretty interesting.
in using it, i believe that it's a little handholdy and reduces expression when every word has some color based on it's part of speech. intentional application of this would be incredibly fun to read, if not incredibly tedious to write
by theokrueger - I found this site very difficult to read and I had to give up as it was hurting – the font is unreadable.
As for syntax highlighting – I don't like it either.
I use themes that change colour according to their nesting level.
by pasc1878 - Yeah, it's just offensive to look at. Makes it significantly less likely that the author has useful things to say about font, highlighting etc. Not gonna bother finding outby nchmy
- I thought about nesting level coloring but had never seen it in action. I just look at it and it indeed looks nice.
I thought it would be interesting as it separates that what repeats a task from the actual work being done on it.
More nesting suggests more complexity.
In my experiments I notice different ways to write something look better with different kinds of highlighting.
If you for example use no highlights dividing the logic over tiny functions looks quite readable.
In one experiment I use dark colors on a black background with only the comments in bright white. I wrote a lot more comments using that. Everything had a description and I could gaze over it as if the code wasn't there.
by econ - I like highlighting only the language concepts:
Reserved words are red
Strings are green
Constants/numbers are blue
Types/meta-language are yellow
Anything else is white.
It’s not too colorful but still gives you plenty of anchors for your eyes.
by burticlies - What about comments? Do you prefer comments to stand out or stand back?by weinzierl
- I use the default neovim theme and I feel that's essentially what I get out of it. Feels like sometimes I don't have highlighting enabled.
- In my case, colors matter because they help me read faster the keywords of a language that define algorithms such as conditionals, loops, beginnings and ends of functions, returns... without color it is more difficult to send the eye to the correct position. Perhaps it's due to habit or visual memory?
Good article that gives you food for thought
by noxss - I couldn’t tell you what colour my functions or structure syntax is, but I can tell you when I look at code, that the presence of the colour instantly lets me straight to whatever part of the text I care about at that moment.by FridgeSeal
- Hmm this wasn't quite what I expected.
I thought that this might be some sort of highlight based on complexity/risk/importance. That immediately struck me as a "why didn't I think of that?!" moment when actually turns out they didn't either.
So I can imagine a scenario where you have a LLM agent's diff to review while iterating in an IDE. The diff would highlighted according to importance/complexity for human review. Trivia like getters and setters would be grey. Highly complex or complicated or risky code would be highlighted in some high-contrast bold colour (perhaps with a luminance scale depending on how critical it was). Then when you are reviewing the diff from the agent you can instantly see and focus on the most important bits that need the most attention.
I'd find that really useful.
by mattlondon - These rethinking-highlighting posts always start out with the wrong premise. The color for class names in my code is the color all the class names have. After a short time working with the code I would notice if one looked off. The brain is really very efficient. You don’t optimise for random out of context recall unless you really try hard to do so. It says nothing about the efficacy of the scheme.by wzdd
- > try to remember what color your color theme uses for class names?
While I overall agree with the point of this post and the post being cited, I disagree with the premise that you need to be able to actively recall facts like this. The theme I personally use is quite toned down, but it does use different colors for variables, keywords, arguments, type names, and a few other classes of tokens. I don’t consciously think “hmm, what color is an argument” to look for those in my code - I just see them, have learned them over the years, and it’s muscle memory at this point, and helps me read the code. Just like I can’t remember the code to my apartment building, yet I type it in multiple times every day.
by nrabulinski - > I disagree with the premise that you need to be able to actively recall facts like this
Same. The goal is to differentiate things. I code mostly in Clojure and I love functional code, so the one thing that really stands out is anything that does mutable things: for example there's swap! in Clojure and that one is "bold fluo blue on a near dark background". I don't use it often, so it sticks out like a sore thumb. But I don't need to remember which hexcode I used for the fluorescent blue: I just know it's obvious.
Same for "rainbow parentheses": it helps visually see where the matching closing parenthesis is without needing to put the cursor on the opening parenthesis (which I can do too if I want).
My color code is mostly toned down too.
- > have learned them over the years
Well I guess that’s the difference? I personally change themes many times per day depending on my mood and the lighting conditions, and probably go through at least a few dozen themes in a year.
I don’t need to memorize colors either though, I look for differences in colors not absolute colors.
by setopt - > Just like I can’t remember the code to my apartment building, yet I type it in multiple times every day.
To me it's even less problematic than this. Not being able to remember important codes except via muscle memory is quite unsettling for me because every now and again my muscle memory fails. Like I will get to an ATM and think "wait - what is my PIN?".
With syntax highlighting, even if my muscle memory fails me I still benefit from syntax highlighting (I think). Because I can immediately see the structure of each line. If I am looking through code for a particular thing, I will probably be able to disregard entire lines because they obviously don't have the structure I am looking for. And even within a line, I can just look at the beginning of each "span", immediately know if it's what I'm looking for, and skip to the next span if it's not.
by NoboruWataya - I am convinced everybody gets syntax highlighting wrong and this article backs me up.
My pet peeves:
- I have no idea how people are supposed to be productive with non-semantic rainbow vomit themes that are so popular in modern editors. I'm too ADHD to want to be overly stimulated by useless information.
- I routinely hate encountering Zig code on Github, where the theme they use turns everything brown. Oh it's because it's a struct member. Dude, everything is a struct member in Zig, it's silly to allocate a vibrant colour for what amounts to 90% of the source code. Random example off my browser history: https://github.com/foxnne/aftersun/blob/main/src/time/enviro...
- Yesterday I opened some Lisp code in KDE's KWrite text editor, and every single default theme highlights parens with a bold font + vibrant colour to make them stand out. Parens in Lisp are supposed to fade in the background, not pop in your face. It was completely unusable, I had to turn off syntax highlighting.
Always seeking good, minimal, muted colour themes for my editors. I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
I remember a colleague that used to write code with syntax highlighting off, and thought that was an eccentric choice. The older I get, the more I appreciate his wisdom. I'd rather have no syntax highlighting than bad one; at least one would try to make the code easy to parse by its structure alone (shorter lines, comments to delimit sections, etc.)
by sph - Maybe a decade ago, I decided to start a theme from scratch, named bland. Initially, it was just black on white, with keywords bold, comments, macro invocations and lifetime tokens (this was all focusing on Rust) italic, and escape sequences bold italic. I decided to wait a week before deciding if I would add any colours at all. As expected, after that week I made strings red, comments green and numbers blue. Since then, I’ve made number type suffixes light blue, macro-related things orange, and delimiters grey (I should try dropping that one again). But things like making type, async, function*, for, const, of, &c. different? No, they’re all just bold black, no need to try distinguishing between them.
I also subsequently made a dark variant of it for my website’s dark mode and for occasions I want to use an editor in a dark place.
The colours involved are all high-contrast, using the RGB channels provided rather than trying to be silly with low contrast: #fff, #000, #c00, #090, #00c to begin with.
But I have no particular interest in publishing this in a form others can consume in whatever editors they use. Plenty of small tweaks that I develop over time, half for my own Vim syntax files. I think the approach itself, of experimenting deliberately yourself, is worthwhile.
by chrismorgan - > Always seeking good, minimal, muted colour themes for my editors. I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
I want the same as you, but probably also the same as you; I'm too lazy to do it myself. Maybe do all of us an favor, and create that yourself and share it with us? I too prefer no syntax highlight than bad one, and most out there are bad, and you clearly grok a bit more than the typical color scheme creator/maintainer, so you're already 50% there! ;)
- > I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
It's programmer art!
by andai - >Always seeking good, minimal, muted colour themes for my editors. I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
I think Prot's Emacs themes are good for this.
- I'm color blind. Most color schemes just fuck up reading. Or they hurt my eyes. I haven't found anything that really convinces me, although having some words in bold does help, but the number should be quite limited. I can see the structure easily enough, so there's no need to emphasize "THERE'S AN IF HERE, IT IS A RESERVED KEYWORD!!".by tgv
- > I have no idea how people are supposed to be productive with non-semantic rainbow vomit themes that are so popular in modern editors.
That depends on what your use for syntax highlighting is. If you use it to find specific types of code, than yeah, it's probably unhelpful. But for me, the point of syntax highlighting is to just make reading easier by separating different parts of the code with different colors. I have absolutely no idea what each color means in my editor, it just matters that they're different.
by flexagoon - > | have no idea how people are supposed to be productive with non-semantic rainbow vomit themes that are so popular in modern editors. I'm too ADHD to want to be overly stimulated by useless information.
At least personally, I've been living with ADHD long enough to have had to learn to cope with the fact that even if I tried to suppress various stimuli in my environment, I'd still find something distracting. Pretty much all of life is filled with background noise for me, so having some of the syntax look noticeably different is not that much of a net increase to distraction for me. To you my color scheme probably looks like "rainbow vomit", but I like bright colors on a black background, and I'm the one who spends all day looking at it, so why should it matter whether you like it as well?
by saghm - Completely with you. I've played with limited syntax highlighting in the past (class names were blue, to answer the question in TFA), but for the past few years I've been running with plain black-on-white, with only a green highlight for comments, and a subtle yellow for strings.
https://i.xkqr.org/lighttheme.png
I think the relatively bold highlighting of comments is important – lots of times I'm the only person to react to incorrect comments because people's themes blur them into the background and they stop reading them.
(But then again, I'm crazy. I colour diffs blue and orange: https://i.xkqr.org/blueyellowdiffs.png inspired by similar advice in https://jameshfisher.com/2014/05/11/your-syntax-highlighter-... I think it has worked to help me notice things other reviewers have not, but it's hard to know for sure.)
by kqr