> Here’s a quick test. Try to find the function definition here
It's funny that in the first example where the author asked the viewers to find the function definition, I was able to do so faster with the colorful syntax highlighting he considered wrong.
To recognize different elements of code is more than just colors, but actual syntaxes of the language and the general shapes of code blocks.
It's a matter of taste, and in my decades of programming, I've found colleagues and many teams trying for all kinds of fancy themes only to come back with a "boring" one, like Material Theme, which is also my main driver nowadays.
I think the author had some good ideas, particularly around literals (what he called constants), rejection of the requirement for equal brightness, and emphasizing comments. The author is more than welcome to bring his version of perfect syntax highlighting to the market of ideas. Its adoption should prove it if his idea wins.
I had the same experience -- it was way easier for me to find it with the rainbow highlighting (even though I already knew where to look when it came to the monochrome highlighting!).
The author later asks what color class definitions were. I think this fundamentally gets wrong how syntax highlighting helps humans. I don't have a clue what color anything is in my favored highlighting, but my brain does incredible pattern recognition to help me digest code in it without me consciously knowing what color does what.
So his arguments for why there's a problem don't hold up, but that doesn't mean there is not in fact a problem.
Yeah I certainly dont' pay attention to or remember what color means what.
I am however in that weird minority that prefers light themes, and I do also prefer minimal syntax highlighting. The author does have a point to an extent, but I don't think there's any one objectively better way to do it I think it's all personal preference.
I don't like the rainbow highlighting, too distracting for me, and doesn't work particularly well with light themes. I did try the author's alabaster theme in VSCode though and it highlights the wrong things for me.
(In C#) if I have var result = await SomeMethodName(param, param, param); It put both "result" and "SomeMethodName" in blue, the rest being black. I'd actually prefer it the other way around, highlight the programming language's keywords (var and await in this case) and leave my own names (result and SomeMethodName) unhighlighted.
The theme was also inconsistent. The post says we shouldn't highlight PL keywords, but the proposed theme does highlight some keywords while ignoring others.
I agree. I was baffled when I realized I was supposed to struggle with that example.
I do agree that it is harder to see the return misspelling with the more detailed syntax highlighting, but when I'm coding I'm mainly focused on the actual tokens I'm writing, and you better believe I pick up on if the syntax highlighting is showing my token as wrongly being a keyword rather than an identifier, or the wrong type of identifier. Even if I don't actually know what the colors are, it will look wrong.
Rainbow vomit syntax highlighting logically seems like a bad idea, but like many things, even though it's hard to prove that it's better, I think a lot of people will agree that it really is better. Especially with tree-sitter and LSPs giving more detailed syntax highlighting; I can feel the benefits of 'oh, that's the wrong identifier color, isn't it?' to the point where if I run into an edge case that breaks highlighting it becomes immediately noticeable.
Same here. To make a base text color more evident, the author smushed elements and lost information. There is no point to a base text color, and it's OK if everything is highlighted, as long as it is consistent.
If "everyone is getting syntax highlighting wrong", it's more likely that you're the one who is getting it wrong.
To this point, I wonder if we can go even further in the direction "it's fine to have a 'zoo' of colors on the screen... as long as we're able to rapidly scan for patterns based on the shapes of code and relative positions of those colors."
Many games (especially gacha games where one may be tracking multiple orthogonal "levels" on any given piece of inventory) compress tremendous amounts of data into a character or gear item portrait; ticks on the top, dots on the side, colored frames, etc. - all so we can pick things out in a crowd without needing to set a custom sort order.
And yet our IDEs, citing silly things like "render optimizations" and "consistency with ANSI escape codes," allow each character to have just a single foreground color, a single background color, and maybe a squiggly underline. Why stop there?
Give me the freedom to add arbitrary overlays and decorations on any given token. Give me <ruby>-style elements [0] that will let me put a little colored dot or emoji at the top right of any token that meets a certain requirement... say, a utility function, or a reference from the file that's open at the top right of my screen.
Let us swim in rainbows with sparkles flying past our eyes. We're strong swimmers.
This is like, it might've been a Veritasium video? There was some YouTube video that started with a test, and the rest was predicted on one outcome but myself and most of the audience had a different one. At worst just read the code normally, at best you can jump to specific colors
> It's funny that in the first example where the author asked the viewers to find the function definition, I was able to do so faster with the colorful syntax highlighting he considered wrong.
Same. It sort of killed the article for me. I also thought that in his resulting theme the limitation of colors would eventually trip me up. Having numbers and strings be the same color is terrible - I have noticed mistakes in the oast where numbers were erroneously attributed as strings for being enclosed in quotation marks precisely because my theme gives those different colors.
The brain picks up on remarkably subtle things, especially when you can leverage its huge pattern recognition cores. I like the argument for having less clutter by default (i.e., prioritizing certain kinds of patterns over others), but it's been less than 40 minutes since an obscure syntactic highlighting based on the type of a variable saved me easily 30 seconds of debugging. It was immediately obviously wrong and immediately fixable. And I'm colorblind. I think you're able to use more colors effectively than the author gives you credit for.
I've tried variations on low-color syntax highlighting (I've even tried no syntax highlighting!). While I agree most color schemes are too colorful, to the point where it's largely noise, I think trying to go super low on colors ends up hurting readability.
For example: keywords, specifically, are actually very useful to highlight. This post complains that misspelling "return" didn't make easily-scannable color changes (it changed the color from purple to red, which still looks like a special color)... But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually! In both cases with the proposed color scheme, "return" and "retunr" would have identical coloring: white.
Generally speaking I think a lot of the visual noise of syntax highlighting comes from having too many colors. For example, you don't need the "class" keyword to have a different color than the "const" keyword — and many syntax highlighting themes are guilty of doing exactly that. But it's useful to be able to immediately, visually see if you made a typo: if you expected to write a keyword, and it's colored like normal text, you know you messed up. Similarly, it's useful when reviewing code to quickly be able to tell whether there's a typo somewhere.
I have a pretty custom syntax highlighting theme for Neovim. I have a few categories that are highlighted differently:
- Keywords
- Function calls and method calls (highlighted identically)
- Property accesses (to highlight mistakes when you're simply accessing a property
instead of calling it — it's a different color than a method call)
- Non-string built-in primitive types like numbers, booleans, etc
- Strings
- Comments
- Types
Ultimately I think syntax highlighting is a tool to let you see mistakes. If you go too wild with the colors, it's true that since everything is a unique color, it's hard to tell when something is the wrong unique color. But you can use a relatively restrained palette and get a lot of value, and I think this post goes a bit too far in terms of reducing color usage.
I learned to code back when there was no syntax highlighting. You had one face, one font, one color on your 80x25 terminal. It might have been green, or amber, or white(ish) but that was it.
I'd prefer minimal-to-no syntax highlighting except for things that should NOT be there. Nonexisting keywords should be highlighted. Unclosed strings. Unbalanced parens or brackets.
I like making comments their own color so you can easily separate them from actual code but I'm otherwise in the minimal camp.
Your thoughts seem similar to mine. Going overboard with the colors just turns it all into visual noise. But cutting down as far as they have removes useful colors.
I've always thought the default Visual Studio color scheme was a nice balance. And I especially like the green comment color in that theme. It doesn't scream for your attention but also doesn't fade into the background (which, annoyingly, many themes do quite literally).
Of course if the author prefers their extra minimal colors I'm not going to tell them they're wrong. Though framing it as objectively better I do disagree with.
> But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually!
Yeah I generally want the opposite. I want keywords to be the thing being highlighted.
I also really dislike overly colorful themes, and I prefer light mode (dark mode is far too hard on my eyes, oddly enough I have to strain to focus or it's fuzzy).
But the author's alabaster theme still highlights the wrong things and is inconsistent.
public async Task<byte[]> SomeMethodName(Type param, Type param) results in Task, SomeMethodName, and BOTh the data type and parameter name being highlighted.
If highlighting isn't for keywords, why is Task and the data types highlighted?
likewise var result = await SomeMethodName(param, param); has result and SomeMethodName highlighted and I generally want the opposite, I want the PL's keywords highlighted and nothing else.
I prefer dark mode (precisely for the garish colors, sorry), but been using light mode... because it's hard to make everything use dark mode!
When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful. Yes, it's super simple for websites to detect the preferred color scheme with @media (prefers-color-scheme: dark) {}, yet most (such as this one) don't. I could use some hacks, but then I'm in for a world of pain. So I just use light theme everywhere and it's ok(ish).
I was like this for a long time, but Dark Reader for Firefox and the default OS dark modes are good enough now I'd rather once in a blue moon fiddle with Dark Reader to correct a bad auto-color-assignment than put up with light mode in my browser and terminal overall. Just a thought. Until the last ~2 years, with win11, latest Linux desktops, and recent macOS all facilitating the change (if i couldn't do it everywhere i might still not do it, y'know? But they all actually work pretty reliably now)
I got started with Notepad on Windows, did that for almost a decade before switching to Linux and learning how to use vim. Definitely prefer the rainbow highlighting to going back to anything close to that.
> Sometimes it gets so bad one can’t see the base text color: everything is highlighted. What’s the base text color here?
I don't understand the premise of this. What is "the base text color" and why would it be important to be able to see it? Everything is assigned some specific color and I don't understand why one of the colors would be considered more important than the others.
> Here’s a quick test. Try to find the function definition here: [...] See what I mean?
No, I don't. From the context I can figure out that the author is arguing that they're easier to find in the second example, but I found it easier with the first. They're both what I would consider pretty bad syntax highlighting schemes, though.
I don't get this either. My code doesn't have "base text"...everything is something! I can see that not being the case for something like HTML, but not for most programming languages.
I must have a very different brain shape than the author. Color processing is for me subconcious, I don't get the "color overload" situation at all because my brain has hardware accelerated it long ago, there is no concious load to track additional colors or pick out differences. The only time I experience that is when looking at someone else's color scheme when pairing.
It lost me after this part:
> Here’s a quick test. Try to find the function definition here:
I found them instantly with more color, and struggled with less, and found the same for all the subsequent examples as well.
> Color processing is for me subconcious, I don't get the "color overload"
Same. I noticed this on a Whatsapp group I have with old friends. About 8 people, so each gets a specific color in their name, and that's how I identify who is talking on a glance.
Once one of them switched thier phone number, and had to leave and reenter the group. This caused the colors of everyone to change.
For a couple of weeks it was hell. I was used to Person A to be pink, Person B to be yellow and so forth. I would reply to A thinking I was replying to B because their color changed, which caused a lot of confusion.
> Please, please don’t highlight language keywords.
Agreed with almost everything the author had to say, but not this. Hard disagree. In my view, keywords are the single most important thing to highlight. I'd be ok without anything else. Keywords sketch the structure of the program in most languages. The thing I want my eye drawn to, in the case of top-level definitions, for example, is the keyword. It's the predictable anchor as I'm scanning a long series of definitions. The identifiers are not: some are long, some are (very) short.
And how do I understand the control flow of my program? I look at keywords. If I want to read the condition, I have to find the condition. But all the conditions look different. What's the reliable way to spot them? The predictable 'if' that precedes each one, without fail.
My eye is a parser. It needs to recognize tokens. But some tokens are easy to confuse: keywords look just like identifiers.
Agreed on this. Especially with the return keyword argument presented in the same article.
An assertion of correctness relating to a matter of taste is, ironically, going to be trivially falsifiable. Even though I found myself personally agreeing with most of what the author had to say (for my tastes)! I definitely want to try lifting the visual importance of comments.
I actually found most of the more colorful examples easier to work with, though I'd probably prefer something more middle-ground the most. That may just be because I use Sublime most of the time and it's more middle-ground itself.
It seems like the author gets most of their value from associating the specific highlight color with a specific meaning. I think I get most of the my value from the different highlight groups. From that perspective, I don't really care if I open an editor and strings are green - I care strings form one group that's different than variable names or etc. The main problem I had with the "complicated" scheme was the reuse of purple: branching, looping, imports, functions, this, new - these are not at all related so making them purple doesn't help me (or the author), regardless of total color count.
I don't think either way is wrong, but it may feel like it to different people.
It is hard to take color advice from someone who thinks it's a good idea for their blog to be black on intense yellow, with code samples light on black background.
I'm not being facetious. The author is trying to show comparisons to the reader of various syntax highlighting schemes, but any difference between them is overwhelmed by the massive contrast between the bright yellow background and the black background of the code samples.
I immediately stopped reading when I saw the yellow. I like colors. I like rainbow delimiters. I will not change at this point. I am okay with minimalistic highlighting. Used to use visual studio with more minimalistic highlighting, and that was fine too. It is a preference and I don't think it is worth indexing much on. If it bothers you, change it until it doesn't. I don't think about it much.
I know. This is literally the ugliest page I saw this year. Bright background, bunch of ugly signs in header, text just gaslighting you about some shit.
No... the best way is to use the same color for all occurrences of the same identifier. So, on the last example, all instances of say "audio" should be of the same color, and those of "filename" of another color.
I tried that for a while but found it's just too colourful. I prefer tasteful colours, somewhere between the two bad extremes demonstrated in this article, but also when you click and identifier it highlights all instances of it.
I agree that certain schemes overdo it with highlighting, but I disagree with his statements that things like function calls and keywords shouldn't be highlighted. Basically, if everything is important then nothing is; but I still want my code to be easily scannable. Right now I'm using using a version of Solarized that uses the default VSCode syntax highlighting and it's been pretty great.
I strongly resonate with the author, as he's articulating thoughts I'm unable to express clearly. It reminds me of the first time I installed colorful themes like Solarized. I immediately felt lost, and most of the themes I used just didn't feel right. They gave me the impression that color schemes are organized for aesthetic purposes only, without any logic or philosophy behind them. I didn't dare to think further because adjusting color schemes always seemed too difficult and prone to breaking things. However, today, thanks to this excellent writing, I finally comprehend the entire concept, and I feel confident in modifying or creating my own themes correctly from now on.
Just created a VSCode theme [1] that looks exactly like the result of "Let’s design a color theme together" in this article. Feel free to try it out! Remember to switch to "GitHub Dark ABS" after installation.
I mostly agree with the author - Christmas tree is a mess. But I also think the final theme was too minimalistic. I find it incredibly helpful when language keywords like "try", "await", or "new" are highlighted.
I agree. Not even highlighting keywords is silly. The overly colourful example he gave is bad, but his alternative is bad in the opposite direction. Middle ground is where it's at.
Asserting that it's impossible or meaningless to measure the quality of a UI is to deny the entire field of UX research. Yes, it's subjective, but you can meaningfully measure the average across many humans. And that's exactly what you should do if you're trying to decide on a UX that will be used by many humans.
Sure, but if you measure that for a ten thousand people (controversially, ten thousand people that aren't already programmers may be better) you can get a good idea of what is efficient and what isn't.
Maybe, but also maybe not. Ten thousand people giving ten thousand uncorrelated responses is also a possible, not unlikely result of such a test. There's also the question of whether or not your methodology for "measuring" what is effective and what isn't is even possible, let alone sufficient for a definitive conclusion.
> If everything is highlighted, nothing is highlighted.
Somewhat related, I got used to turning off syntax highlighting for some coding sessions.
It started when I was using vim to edit large data files and syntax highlighting there was buggy.
Later, I worked with large react files, where with each JSX block the latency and highlighting reliability was getting worse. So I turned it off too and I was surprised that I didn’t see a big difference in readability after that.
I’d still use syntax highlighting for backend work. But I don’t mind looking at large html files or react prototypes sans highlighting.
> Close your eyes (not yet! Finish this sentence first) and try to remember what color your color theme uses for class names? Can you? If the answer for both questions is “no”, then your color theme is not functional.
I'm sure this varies person-to-person, but for me at least this is not a good test.
I couldn't list the notes in Clair De Lun, but I'd certainly notice if I heard the wrong note played. In much the same way, I have no idea what color classes are in my theme, but I certainly notice when it's wrong.
Yeah it holds no water whatsoever. I can pick out every person in my family just by the cadence of their footsteps, but it you ask me to recreate or remember it, I'd be at a complete loss
The diagnosis is valid but the prescription is incorrect.
The solution is not to use fewer colors, but rather to take advantage of the 3D space of color perception.
Good themes have a hierarchy. Perhaps red is for keywords and blue is for symbols, but different kinds of symbols have different shades of blue. A lighter blue for functions, a darker blue for classes, for example.
This allows the highlighting to convey a higher amount of information when reading code closely, without causing distraction when skimming through code.
Like many comments here, I disagree with this article.
Notably, I don't necessarily remember which colors are used by my code editors off the top of my head, but you can be damn sure that if the smallest thing is different tomorrow, I will notice, and if anything is the wrong color, I will immediately notice something is wrong. Put as many colors as possible and it makes it easier for me to spot any mistake. Although I can understand that more than a few colors can be distracting to some people.
As for "everyone does it wrong", and in particular wtt the Christmas tree effect, I find Kate's and IDEA's default color themes quite well designed and balanced, and where each sub expression start and end.
I do find light themes far more readable, and only use dark themes under very bad lighting conditions where a white background would hurt the eyes even at minimal screen brightness.
Bonus topic: in the Christmas tree screenshots, you can notice that parentheses are of different colors. This creates a visual mess but I do activate this option in Kate anyway because it is very useful to quickly check that the parentheses are balanc
It's less necessary when you have syntax checking though, because the editor will put a red background or draw squiggles.
The primary difference is that my theme has an underlying assumption that colors have semantic meaning that we all implicitly understand(red = bad, yellows/oranges are action-oriented etc). So instead of color = syntax, my theme semantically maps color = intent.
• Warm colors (orange/red) for actions — throw, return, await.
• Cool colors (blue/green) for definitions and values — function names, constants, variables.
• Muted neutrals for structure and noise — punctuation, keywords like var or const
This means comments are muted, contrary to the author's proposal - imo while they are important and helpful, they're secondary to the actual code
My primary design goal was that if you open a large file and squint at it, the flow should be immediately obvious (the flow colors stand out, if you see a bunch of blues it's calling a bunch of other functions etc)
I love the concept of lexical differential highlighting [0] (discussed here [1]). It makes reading math so much easier, especially in dense code. However I don't know of any editor that implements a feature like this.
If you paste the following code into the example block in [0] you can see how useful this can be:
while (b - a).abs() > EPSILON {
let c = a + (a - b) * f_a / (f_b - f_a);
let f_c = J(c);
if f_c * f_b == 0.0 {
a = b;
f_a = f_b;
} else {
f_a /= 2.0;
}
b = c;
f_b = f_c;
}
Keywords should definitely be highlighted. It's part of the structure of the code. Being highlighted makes it very quick to distinguish between keywords and variables and helps readability by making them easier to skim over and jump to. Maybe they could be the same color as punctuation, if number of colors is a problem.
I also like minimal themes (and light mode!) but keywords are precicesly the thing I want highlighted. The "Visual Studio(Light)" theme in VSCode gets it pretty close to what I want but still has some inconsitencies that bug me but I haven't bothered making my own to fix them yet. It primarily just highlights keywords, comments, strings.
But then you can have something like public async Task<byte[]> SomeMethod(DateTime date, int someNumber) and int is highlighted but DateTime isn't...
I like the dark color-scheme because the light color-schemes look like a lighthouse has been built on my desktop; it is an affront to my senses and burns my eyeballs.
I have no idea where I got it, but I have a quick JavaScript bookmarklet that darkens any page for me in an instant. I love it. And I, unfortunately, have to use it every time here on Hacker News.
> Most languages don’t distinguish between those, so there’s not much you can do syntax-wise. Sometimes there’s a convention (e.g. -- vs /* */ in SQL), then use it!
I do this in C to: /* */ for explanation, // for temporary disabled.
Are we sure this guy isn't trolling us? The advice about theming while using a yellow-on-black blog format, the "dark mode" toggle which makes the whole page black except for a spotlight focused on the mouse cursor... I'm not sure.
They’re not talking about the squiggly line. The word return/retunr gets highlighted in slightly different colors based on whether the highlighter is picking it up as a keyword or a variable name, but in the scheme the colors are similar.
But their argument is based on the underlying assumption that it's the responsibility of the syntax highlighter to tell you when you've made a typo.
I am presenting an argument against this - and stating it's the responsibility of _diagnostics_ to tell you when you've made a typo, not syntax highlighting.
I would add that no highlighting would be applied to this mistyped word as it would not be recognised as a variable or a keyword. This may depend on the way syntax highlighting is handled. A common solution like treesitter would sus out that no variable with the name retunr exists, probably causing the mythical base colour to be applied, heh. That is arguably a big highlight in a colourscheme that rarely uses its base colour.
I thought that the judicious use of colors would be universally regarded as sound advice [1]. But again, you can never get an online forum to reach a consensus on anything.
I like having the identifiers of function/method calls being a distinguishable colour, because when looking at an overall section of code, they are the 'wormholes' to other code, and so one of the most useful things to be able to pick out instantly at a glance.
But I agree with the author that if little to nothing ends up being given the base text colour (e.g. white or black) then the design is an unthinking one (less of a design process, more of a box-ticking exercise to assign a unique colour to everything that can possibly have one).
Nowadays "syntax highlighting" acutally means "syntax colorization" more. It's purpose is not just to mark specific tokens/lexemes/phrases (as in compiler principles), but to differentiate between them. Making something "stand out" is no longer the goal No.1. Human minds are not automata, so colorization actually helps a lot in parsing and preprocessing the text beforehand.
It's also pretty easy to take a theme you like and make tweaks. I have a local VS Code "extension" which is my custom color theme (never bothered to publish it).
1. I find it pretty suspect you intentionally don't use the default syntax highlighting in vscode, the editor you're using, as your baseline. Many of your comments just wouldn't hold nearly as much water if you did.
2. having keywords vs variable names vs functions be different colors helps you find misspellings, not the other way around. But that's almost beside the point, because it's your linter/intellisense/error checker's job to let you know when you have an obvious syntax error. You're also taking this as if you've just discovered this code block in the ether and have to debug it, rather that the reality that if you had actually been the author, you would have immediately noticed it, even without red squiggles, because it would be immediately obvious when you type it that it doesn't highlight as a keyword. Human brains are hardwired for pattern recognition, one could even argue it's the only thing the human brain is even good at.
3. I'm not sure where the notion of comments being grey is "tradition", but in practically every editor I've used, the default color for comments is a pretty easy to pick out green. Comments usually stick out like a sore thumb, in fact, as they typically don't share their color with any other syntax. Again, this points to you specifically picking out a non-default theme to make your points against.
4. "... gets so bad you can't see the base color" this isn't so much a thing, rather, the base color just isn't white. Which is because most people would agree that pure white on black is not pleasant to look at for long periods of time. There's a reason you don't see many dark mode highlighters use white. Again, default for vscode is a pleasant light blue. Plenty of contrast, but not so harsh it strains your eyes.
5. This is the most psychological, and subjective one, but plain, unhighlighted text just doesn't look like code. It looks like plaintext. Because plaintext is unstructured. Syntax highlighting brings out (highlights) the inherent structure of code. And that's kind of the entire point; it's there to show the structure. It may help you spot a typo, but that's not why it's there. That's an incidental perk. It's there because our brains are really good at pattern recognition, and having syntax follow a predictable color scheme taps in to that pattern recognition.
I'd say way more damage occurs when people neglect warnings and errors.
Like literally IDE not just highlights, it underscores a problem in red/yellow, puts a marker on the left of line, and on the right at the scrollbar as well. Also marks the whole file tab and file name on project tree. Gives a warning when user creates a commit.
Still, many, too many programmers don't care to either fix or silence it.
To each their own. If anything I tend to go farther, like using different tints for async vs sync functions in python and gdscript.
What'd be nice would be easier customization of these rules in your ide, like quick email rule creation in Outlook. Select what you want to alter, the rule modal shows you a couple options for targeting, then you can apply whatever highlighting you want.
I seem to be the only person here who prefers the author’s approach!
The combination of adhd and colorblindness seems to make most multicolor displays just visual snow to me. It’s like looking at one of those magic eye pictures. I struggle with foreground/background in both vision and hearing, and it took quite a long time to realize others don’t process like that.
Here's an idea that hopefully will inspire something. You could use major color differences for large semantic differences (numeric literal vs. comment), midrange color differences for intermediate semantic differences (function call vs. local variable) and small color differences for small semantic differences (local variable vs. class member).
I recently switched from PyCharm to VSCode and the feature I miss the most is the bold yellow highlight of the symbol under the caret that was the only custom config I had in PyCharm. VSCode only allows a weak «box» around it which I struggle to see when scanning code quickly and I haven’t managed to find a good solution.
If is not highlighting structure then is failing to do the pre-optimization that helps your organic parser do that.
The "matter of taste" part can come after the "matter of structure" was adequately elevating the right categories of elements to each level, hence inviting to receive the required attention.
This is a really insightful post. I created a Vim color scheme that uses even fewer colors than his but I didn’t realize that you might want to express nesting through varying lightness levels. I also didn’t realize that using HSLuv and making all lightness uniform might actually hurt the scheme.
I thought this was going to be about highlighting based on symbol type or identity instead of language syntax, like all instances of the same type or function or variable would be the same unique color. I think I saw a vscode extension for that a long time ago, does anyone use it?
I have used Tao theme in Emacs along with rainbow identifiers for over a decade now (on light mode) and I personally prefer a less colorful palette on my text editor. Makes a nice contrast with my eboy tokyo/San Francisco backgrounds which I also love dearly.
Aside from the rest of the (interesting!) nuanced discussion going on the comments here -- I really like his idea towards the bottom of combining the colors for numbers and strings into one.
Needs examples of what a few common editors and IDEs use by default to make the case of what they do well and don't, at least in conjunction with the title. What does RustRover do well? Poorly? What about Github in-browser/ VsCode with its deafult Python config?
I agree with the over highlighted examples being over highlighted but the author's preferred schemes are even worse, especially with different background colors. I guess everyone has their own opinion and thankfully there are plenty of options.
I'm surprised not to see any comments about rainbow brackets for the Lisp family of languages. I just started in a non-Emacs environment to avoid learning two things, but colourful brackets have made the paradigm shift a lot easier for me.
> Here’s a quick test. Try to find the function definition here
This is only an issue for websites and they generally have short code snippets anyway. I’ve been using the same theme in my editor for the last 10 years so it is much more useful there.
I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.
My scheme is a bit modest. Comments, keywords, and string literals are highlighted. The rest is just black on white. I tend to agree that less is more.
I agree with everything the author said here, but unfortunately no mention at all of semantic highlighting! This is the killer feature for me and I literally cannot do without it.
Your preference for light and dark mode doesnt change with the ambient light?
Im always surprised by the number of people who will delcare one absolutely better than the other without consideration for this factor. Sure, people have some general preferences, but I thnk it's 90% about the ambient light.
If it's pitch black most people will prefer dark and if it's bright daylight people will prefer light.
F.lux / Redshift / Gammastep exist. On sunset, my screen becomes much darker and tinted yellowish / reddish. Then white backgrounds look fine, and I happily continue using my light color themes late into the night. Also, bias lighting on the wall behind the monitor helps my eyes avoid strain.
> (And of course white background always. Dark mode is depressing.)
Twice during the last couple of years, I’ve done this poll online:
When reading a code block in your chosen viewing mode (light or dark),
which of these should the code block always do?
- Match my chosen mode
- Have a dark background
- Have a light background
... and, each time, “Match my chosen mode” won with well over 75% of the votes (about 150–200 total votes in each case). Accordingly, I’ve styled my site’s code blocks to handle both dark- and light-mode viewing. I also provide a switch that enables one to toggle back and forth just in case the chosen system mode doesn’t match how one wants to view code blocks (e.g., some people prefer to see code blocks in dark mode even if they’re otherwise using light mode).
After a couple of years working in Smalltalk, I’ve acquired the hot take that all the code should be in a proportional font. Admittedly it doesn’t work quite as well for brace syntax languages, but in Smalltalk and Python it’s great.
I was prepared to hate this article based on the clickbaity headline "...everyone is getting syntax highlighting wrong". But I agree with the premise, and I find his proposed scheme a lot better than some of the most popular colour schemes that I see online.
But I use the Nord colour scheme in VS Code, and it appears to follow the same principles as what the author proposes. There are only a few colours, with a lot of the code remaining in the base colour. Also, Python comments starting with `#` are dimmed, but comments in triple-quote blocks are highlighted. The funny thing is that I had never even noticed this, it just seemed to be intuitive.
In my experience I have never once thought about what color means what, but if the colors are wrong I can "sense" that something is broken. It almost becomes a second sense, the patterns are recognized somewhere deep in my mammal brain
Sorry, but 'my preference is x. Therefore y. Science' is not how any of this works. I get that it's a joke, but considering light themes are objectively superior (c. ref. <https://journals.sagepub.com/doi/abs/10.1177/154193121360181...>), I take umbrage.
I mean, any of those would work, but the one that works best is the one you're used to.
The brain is great at learning patterns, I'm extremely used to IntelliJ's classic theme (light) with Firacode with ligatures.
But that's me, I've been daily driving that for years, so stuff just pops up at me.
I like semantic highlights (i.e. something is static or a field, or whatever) rather than pure syntactic ones, but what matters most to me is stability.
If it changes for no reason, it's jarring and takes a while to get used to it again.
I've done a lot of experiments. Most turned out wonderful ways to ruin readability. (I combine those to highlight a single line of code in an article to troll the reader)
It is a huge problem that we are so used to what we have. I can barely make sense of the examples in the article.
I think it calls for actual research where we collectively catalog the approaches, experiment (on humans) and attempt to have conclusions about them.
What surprised me most in the experiments is that giving each different variable and each function call a different color makes scanning over the code much easier.(function declaration and call the same color)
Also a very successful experiment was to color the opening and closing brackets the same color and use a different one for each level of nesting.
One that I failed to code/design properly but looked very promising was to faintly color the background of each level of nesting so that the color gets more visible the deeper you go. It makes the hot spots jump out.
Probably the funniest was to have basic html tags in comments (like headings, pictures and videos) then define a css at the top of the code.
/*<style>
body {background:Medium Blue;color:white}
comments {color:lime}
var {color:olive}
h1 {font-family:inferno}
</style>*/
I’m the same way. The squiggly lines would tell me if `return` is spelled wrong more than a slightly off color would.
But colors help me separate “this whole thing is a string” from “this is a string but with code inside it”. Comments being gray doesn’t make them less visible for me, just visibly different which is all I’m looking for.
99% of the colors don’t actually matter to me. It’s the distinguishing of conceptual elements that are adjacent to each other that matters more to me.
I get the impression you did not follow through with the whole article, as that is the point being made. In the colorful examples, variable declaration, access, parameters, method calls and event the mistyped return have similar colors, making the token types indistinguishable. There are also way too many colors to be able to recall anything.
Removing color from variables is a bit too far for me though, I expect the declaration and any subsequent access to be visually consistent.
Another “everyone’s doing this highly subjective thing wrong” post. Why do you think there are so many color schemes, my guy? Pick the one that works for you and move along.
I find that i adapt to color schemes pretty quickly and subconsciously. Using the same theme and going from JavaScript to Java, for example, you'll see a lot of different colors on average--lots more class names in Java, for example, so lots more red, in my case. But to me it's less about what color means what, and more about the patterns. If other strings are yellow and mine isn't, problem. If the name I'm using doesn't match the function argument I'm expecting to use, maybe i need a `this.`.
It does seem self evidently bad to use the same color for multiple different things. I feel like bold and italic text can be helpful there, like maybe you reuse a color but change the style depending on context.
Honestly i think when the majority of the content is one color, my brain just writes it off as one big block of stuff to skim over, whereas everything with it's own color actually makes more sense to me.
And yeah, i didn't spot the "retunr", but if i were typing it in real time and the word didn't match my mental map for "return," i probably would still notice.
In my experience low-color guys were either uber-programmer greybeards or fucking morons cargo-culting uber-programmer greybeards. Most bimodal property ever. You don't find that with vim bindings etc.
I wonder which software engineer traits are like this. Maybe everything that it's kind of low-friction to do. If you had a CRT screen you're probably a details oriented person. If you've got conky running you're from the time when you needed to watch those things or you're a moron cargo culting that.
> Here’s a quick test. Try to find the function definition here
It's funny that in the first example where the author asked the viewers to find the function definition, I was able to do so faster with the colorful syntax highlighting he considered wrong.
To recognize different elements of code is more than just colors, but actual syntaxes of the language and the general shapes of code blocks.
It's a matter of taste, and in my decades of programming, I've found colleagues and many teams trying for all kinds of fancy themes only to come back with a "boring" one, like Material Theme, which is also my main driver nowadays.
I think the author had some good ideas, particularly around literals (what he called constants), rejection of the requirement for equal brightness, and emphasizing comments. The author is more than welcome to bring his version of perfect syntax highlighting to the market of ideas. Its adoption should prove it if his idea wins.
I had the same experience -- it was way easier for me to find it with the rainbow highlighting (even though I already knew where to look when it came to the monochrome highlighting!).
The author later asks what color class definitions were. I think this fundamentally gets wrong how syntax highlighting helps humans. I don't have a clue what color anything is in my favored highlighting, but my brain does incredible pattern recognition to help me digest code in it without me consciously knowing what color does what.
So his arguments for why there's a problem don't hold up, but that doesn't mean there is not in fact a problem.
Yeah I certainly dont' pay attention to or remember what color means what.
I am however in that weird minority that prefers light themes, and I do also prefer minimal syntax highlighting. The author does have a point to an extent, but I don't think there's any one objectively better way to do it I think it's all personal preference.
I don't like the rainbow highlighting, too distracting for me, and doesn't work particularly well with light themes. I did try the author's alabaster theme in VSCode though and it highlights the wrong things for me.
(In C#) if I have var result = await SomeMethodName(param, param, param); It put both "result" and "SomeMethodName" in blue, the rest being black. I'd actually prefer it the other way around, highlight the programming language's keywords (var and await in this case) and leave my own names (result and SomeMethodName) unhighlighted.
The theme was also inconsistent. The post says we shouldn't highlight PL keywords, but the proposed theme does highlight some keywords while ignoring others.
I agree. I was baffled when I realized I was supposed to struggle with that example.
I do agree that it is harder to see the return misspelling with the more detailed syntax highlighting, but when I'm coding I'm mainly focused on the actual tokens I'm writing, and you better believe I pick up on if the syntax highlighting is showing my token as wrongly being a keyword rather than an identifier, or the wrong type of identifier. Even if I don't actually know what the colors are, it will look wrong.
Rainbow vomit syntax highlighting logically seems like a bad idea, but like many things, even though it's hard to prove that it's better, I think a lot of people will agree that it really is better. Especially with tree-sitter and LSPs giving more detailed syntax highlighting; I can feel the benefits of 'oh, that's the wrong identifier color, isn't it?' to the point where if I run into an edge case that breaks highlighting it becomes immediately noticeable.
Same here. To make a base text color more evident, the author smushed elements and lost information. There is no point to a base text color, and it's OK if everything is highlighted, as long as it is consistent.
If "everyone is getting syntax highlighting wrong", it's more likely that you're the one who is getting it wrong.
I wonder if OP has some kind of color blindness that makes his examples make more sense?
I am able to parse the status quo example way better than his ideas.
My theory is helped by his use of a yellow background on black text, which is horrific to read.
Black on yellow is one of the most striking contrasts, I wonder what you think is horrific?
To this point, I wonder if we can go even further in the direction "it's fine to have a 'zoo' of colors on the screen... as long as we're able to rapidly scan for patterns based on the shapes of code and relative positions of those colors."
Many games (especially gacha games where one may be tracking multiple orthogonal "levels" on any given piece of inventory) compress tremendous amounts of data into a character or gear item portrait; ticks on the top, dots on the side, colored frames, etc. - all so we can pick things out in a crowd without needing to set a custom sort order.
And yet our IDEs, citing silly things like "render optimizations" and "consistency with ANSI escape codes," allow each character to have just a single foreground color, a single background color, and maybe a squiggly underline. Why stop there?
Give me the freedom to add arbitrary overlays and decorations on any given token. Give me <ruby>-style elements [0] that will let me put a little colored dot or emoji at the top right of any token that meets a certain requirement... say, a utility function, or a reference from the file that's open at the top right of my screen.
Let us swim in rainbows with sparkles flying past our eyes. We're strong swimmers.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
This is like, it might've been a Veritasium video? There was some YouTube video that started with a test, and the rest was predicted on one outcome but myself and most of the audience had a different one. At worst just read the code normally, at best you can jump to specific colors
Same for me, my eyes just jumped from function keyword to keyword
> It's funny that in the first example where the author asked the viewers to find the function definition, I was able to do so faster with the colorful syntax highlighting he considered wrong.
Same. It sort of killed the article for me. I also thought that in his resulting theme the limitation of colors would eventually trip me up. Having numbers and strings be the same color is terrible - I have noticed mistakes in the oast where numbers were erroneously attributed as strings for being enclosed in quotation marks precisely because my theme gives those different colors.
The brain picks up on remarkably subtle things, especially when you can leverage its huge pattern recognition cores. I like the argument for having less clutter by default (i.e., prioritizing certain kinds of patterns over others), but it's been less than 40 minutes since an obscure syntactic highlighting based on the type of a variable saved me easily 30 seconds of debugging. It was immediately obviously wrong and immediately fixable. And I'm colorblind. I think you're able to use more colors effectively than the author gives you credit for.
I've tried variations on low-color syntax highlighting (I've even tried no syntax highlighting!). While I agree most color schemes are too colorful, to the point where it's largely noise, I think trying to go super low on colors ends up hurting readability.
For example: keywords, specifically, are actually very useful to highlight. This post complains that misspelling "return" didn't make easily-scannable color changes (it changed the color from purple to red, which still looks like a special color)... But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually! In both cases with the proposed color scheme, "return" and "retunr" would have identical coloring: white.
Generally speaking I think a lot of the visual noise of syntax highlighting comes from having too many colors. For example, you don't need the "class" keyword to have a different color than the "const" keyword — and many syntax highlighting themes are guilty of doing exactly that. But it's useful to be able to immediately, visually see if you made a typo: if you expected to write a keyword, and it's colored like normal text, you know you messed up. Similarly, it's useful when reviewing code to quickly be able to tell whether there's a typo somewhere.
I have a pretty custom syntax highlighting theme for Neovim. I have a few categories that are highlighted differently:
- Keywords
- Function calls and method calls (highlighted identically)
- Property accesses (to highlight mistakes when you're simply accessing a property instead of calling it — it's a different color than a method call)
- Non-string built-in primitive types like numbers, booleans, etc
- Strings
- Comments
- Types
Ultimately I think syntax highlighting is a tool to let you see mistakes. If you go too wild with the colors, it's true that since everything is a unique color, it's hard to tell when something is the wrong unique color. But you can use a relatively restrained palette and get a lot of value, and I think this post goes a bit too far in terms of reducing color usage.
I learned to code back when there was no syntax highlighting. You had one face, one font, one color on your 80x25 terminal. It might have been green, or amber, or white(ish) but that was it.
I'd prefer minimal-to-no syntax highlighting except for things that should NOT be there. Nonexisting keywords should be highlighted. Unclosed strings. Unbalanced parens or brackets.
I like making comments their own color so you can easily separate them from actual code but I'm otherwise in the minimal camp.
Your thoughts seem similar to mine. Going overboard with the colors just turns it all into visual noise. But cutting down as far as they have removes useful colors.
I've always thought the default Visual Studio color scheme was a nice balance. And I especially like the green comment color in that theme. It doesn't scream for your attention but also doesn't fade into the background (which, annoyingly, many themes do quite literally).
Of course if the author prefers their extra minimal colors I'm not going to tell them they're wrong. Though framing it as objectively better I do disagree with.
> But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually!
Yeah I generally want the opposite. I want keywords to be the thing being highlighted.
I also really dislike overly colorful themes, and I prefer light mode (dark mode is far too hard on my eyes, oddly enough I have to strain to focus or it's fuzzy).
But the author's alabaster theme still highlights the wrong things and is inconsistent.
public async Task<byte[]> SomeMethodName(Type param, Type param) results in Task, SomeMethodName, and BOTh the data type and parameter name being highlighted.
If highlighting isn't for keywords, why is Task and the data types highlighted?
likewise var result = await SomeMethodName(param, param); has result and SomeMethodName highlighted and I generally want the opposite, I want the PL's keywords highlighted and nothing else.
> prefer light mode
I prefer dark mode (precisely for the garish colors, sorry), but been using light mode... because it's hard to make everything use dark mode!
When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful. Yes, it's super simple for websites to detect the preferred color scheme with @media (prefers-color-scheme: dark) {}, yet most (such as this one) don't. I could use some hacks, but then I'm in for a world of pain. So I just use light theme everywhere and it's ok(ish).
I was like this for a long time, but Dark Reader for Firefox and the default OS dark modes are good enough now I'd rather once in a blue moon fiddle with Dark Reader to correct a bad auto-color-assignment than put up with light mode in my browser and terminal overall. Just a thought. Until the last ~2 years, with win11, latest Linux desktops, and recent macOS all facilitating the change (if i couldn't do it everywhere i might still not do it, y'know? But they all actually work pretty reliably now)
> I've even tried no syntax highlighting!
I got started with Notepad on Windows, did that for almost a decade before switching to Linux and learning how to use vim. Definitely prefer the rainbow highlighting to going back to anything close to that.
> Sometimes it gets so bad one can’t see the base text color: everything is highlighted. What’s the base text color here?
I don't understand the premise of this. What is "the base text color" and why would it be important to be able to see it? Everything is assigned some specific color and I don't understand why one of the colors would be considered more important than the others.
> Here’s a quick test. Try to find the function definition here: [...] See what I mean?
No, I don't. From the context I can figure out that the author is arguing that they're easier to find in the second example, but I found it easier with the first. They're both what I would consider pretty bad syntax highlighting schemes, though.
I don't get this either. My code doesn't have "base text"...everything is something! I can see that not being the case for something like HTML, but not for most programming languages.
I must have a very different brain shape than the author. Color processing is for me subconcious, I don't get the "color overload" situation at all because my brain has hardware accelerated it long ago, there is no concious load to track additional colors or pick out differences. The only time I experience that is when looking at someone else's color scheme when pairing.
It lost me after this part:
> Here’s a quick test. Try to find the function definition here:
I found them instantly with more color, and struggled with less, and found the same for all the subsequent examples as well.
> Color processing is for me subconcious, I don't get the "color overload"
Same. I noticed this on a Whatsapp group I have with old friends. About 8 people, so each gets a specific color in their name, and that's how I identify who is talking on a glance.
Once one of them switched thier phone number, and had to leave and reenter the group. This caused the colors of everyone to change.
For a couple of weeks it was hell. I was used to Person A to be pink, Person B to be yellow and so forth. I would reply to A thinking I was replying to B because their color changed, which caused a lot of confusion.
It just seems like some people prefer highlighting in the literal traditional sense while others like the more common color coordinated code.
> Please, please don’t highlight language keywords.
Agreed with almost everything the author had to say, but not this. Hard disagree. In my view, keywords are the single most important thing to highlight. I'd be ok without anything else. Keywords sketch the structure of the program in most languages. The thing I want my eye drawn to, in the case of top-level definitions, for example, is the keyword. It's the predictable anchor as I'm scanning a long series of definitions. The identifiers are not: some are long, some are (very) short.
And how do I understand the control flow of my program? I look at keywords. If I want to read the condition, I have to find the condition. But all the conditions look different. What's the reliable way to spot them? The predictable 'if' that precedes each one, without fail.
My eye is a parser. It needs to recognize tokens. But some tokens are easy to confuse: keywords look just like identifiers.
Agreed on this. Especially with the return keyword argument presented in the same article.
An assertion of correctness relating to a matter of taste is, ironically, going to be trivially falsifiable. Even though I found myself personally agreeing with most of what the author had to say (for my tastes)! I definitely want to try lifting the visual importance of comments.
I don't think keywords need to have a distinct color, though. It's enough to just use the base color and make it bright and/or bold.
I kind of agree, but I think it might be ok to turn off keywords sometimes, unless broken. Highlight "retunr" in reverse video.
I actually found most of the more colorful examples easier to work with, though I'd probably prefer something more middle-ground the most. That may just be because I use Sublime most of the time and it's more middle-ground itself.
It seems like the author gets most of their value from associating the specific highlight color with a specific meaning. I think I get most of the my value from the different highlight groups. From that perspective, I don't really care if I open an editor and strings are green - I care strings form one group that's different than variable names or etc. The main problem I had with the "complicated" scheme was the reuse of purple: branching, looping, imports, functions, this, new - these are not at all related so making them purple doesn't help me (or the author), regardless of total color count.
I don't think either way is wrong, but it may feel like it to different people.
It is hard to take color advice from someone who thinks it's a good idea for their blog to be black on intense yellow, with code samples light on black background.
I'm not being facetious. The author is trying to show comparisons to the reader of various syntax highlighting schemes, but any difference between them is overwhelmed by the massive contrast between the bright yellow background and the black background of the code samples.
I think it's fine. Better than purple on dark-grey that I've seen posted here.
yellow? had to go back to check - Try Darkreader :)
Dang, that was hard on the eyes..
I think it's fine and it's certainly very recognizable
I agree with the advice but yeah, this website burned my eyes
Agreed, I had to check a couple of other pages on his site to make sure it wasn't ironically done for just that particular post.
I immediately stopped reading when I saw the yellow. I like colors. I like rainbow delimiters. I will not change at this point. I am okay with minimalistic highlighting. Used to use visual studio with more minimalistic highlighting, and that was fine too. It is a preference and I don't think it is worth indexing much on. If it bothers you, change it until it doesn't. I don't think about it much.
I know. This is literally the ugliest page I saw this year. Bright background, bunch of ugly signs in header, text just gaslighting you about some shit.
No... the best way is to use the same color for all occurrences of the same identifier. So, on the last example, all instances of say "audio" should be of the same color, and those of "filename" of another color.
Original idea from here: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e
One impl for Emacs: https://github.com/ankurdave/color-identifiers-mode
I still admire you Niki.
I tried that for a while but found it's just too colourful. I prefer tasteful colours, somewhere between the two bad extremes demonstrated in this article, but also when you click and identifier it highlights all instances of it.
I ironically use the author light theme.
https://github.com/tonsky/vscode-theme-alabaster
Seems to break all his rules from the blog post.
The best book I know on subject of how to best display computer programs is:
Human Factors and Typography for More Readable Programs https://www.amazon.com/-/he/Ronald-M-Baecker/dp/0201107457
On the archive at https://archive.org/details/humanfactorstypo0000baec
I agree that certain schemes overdo it with highlighting, but I disagree with his statements that things like function calls and keywords shouldn't be highlighted. Basically, if everything is important then nothing is; but I still want my code to be easily scannable. Right now I'm using using a version of Solarized that uses the default VSCode syntax highlighting and it's been pretty great.
I strongly resonate with the author, as he's articulating thoughts I'm unable to express clearly. It reminds me of the first time I installed colorful themes like Solarized. I immediately felt lost, and most of the themes I used just didn't feel right. They gave me the impression that color schemes are organized for aesthetic purposes only, without any logic or philosophy behind them. I didn't dare to think further because adjusting color schemes always seemed too difficult and prone to breaking things. However, today, thanks to this excellent writing, I finally comprehend the entire concept, and I feel confident in modifying or creating my own themes correctly from now on.
Just created a VSCode theme [1] that looks exactly like the result of "Let’s design a color theme together" in this article. Feel free to try it out! Remember to switch to "GitHub Dark ABS" after installation.
[1]: https://marketplace.visualstudio.com/items?itemName=reorx.gi...
I mostly agree with the author - Christmas tree is a mess. But I also think the final theme was too minimalistic. I find it incredibly helpful when language keywords like "try", "await", or "new" are highlighted.
I agree. Not even highlighting keywords is silly. The overly colourful example he gave is bad, but his alternative is bad in the opposite direction. Middle ground is where it's at.
"In matters of taste, there can be no dispute." -dad
This isn’t just a matter of taste. The colors exist to aid in the task of coding. How well they do that is measurable.
Sure, but how well they do that for each individual person is, well, individual...
Asserting that it's impossible or meaningless to measure the quality of a UI is to deny the entire field of UX research. Yes, it's subjective, but you can meaningfully measure the average across many humans. And that's exactly what you should do if you're trying to decide on a UX that will be used by many humans.
Sure, but if you measure that for a ten thousand people (controversially, ten thousand people that aren't already programmers may be better) you can get a good idea of what is efficient and what isn't.
Maybe, but also maybe not. Ten thousand people giving ten thousand uncorrelated responses is also a possible, not unlikely result of such a test. There's also the question of whether or not your methodology for "measuring" what is effective and what isn't is even possible, let alone sufficient for a definitive conclusion.
> If everything is highlighted, nothing is highlighted.
Somewhat related, I got used to turning off syntax highlighting for some coding sessions.
It started when I was using vim to edit large data files and syntax highlighting there was buggy.
Later, I worked with large react files, where with each JSX block the latency and highlighting reliability was getting worse. So I turned it off too and I was surprised that I didn’t see a big difference in readability after that.
I’d still use syntax highlighting for backend work. But I don’t mind looking at large html files or react prototypes sans highlighting.
I thought we all agreed that Turbo Pascal/C had the best color scheme?
No, we didn't agree on anything - especially if by "we" you mean "all of HN" or, worse, "all of software engineering".
Except tabs versus spaces, which ended back in 2021 we all decided the best indentation was the emoji corn.
Those were the days!
> Close your eyes (not yet! Finish this sentence first) and try to remember what color your color theme uses for class names? Can you? If the answer for both questions is “no”, then your color theme is not functional.
I'm sure this varies person-to-person, but for me at least this is not a good test.
I couldn't list the notes in Clair De Lun, but I'd certainly notice if I heard the wrong note played. In much the same way, I have no idea what color classes are in my theme, but I certainly notice when it's wrong.
Yeah it holds no water whatsoever. I can pick out every person in my family just by the cadence of their footsteps, but it you ask me to recreate or remember it, I'd be at a complete loss
The diagnosis is valid but the prescription is incorrect.
The solution is not to use fewer colors, but rather to take advantage of the 3D space of color perception.
Good themes have a hierarchy. Perhaps red is for keywords and blue is for symbols, but different kinds of symbols have different shades of blue. A lighter blue for functions, a darker blue for classes, for example.
This allows the highlighting to convey a higher amount of information when reading code closely, without causing distraction when skimming through code.
Like many comments here, I disagree with this article.
Notably, I don't necessarily remember which colors are used by my code editors off the top of my head, but you can be damn sure that if the smallest thing is different tomorrow, I will notice, and if anything is the wrong color, I will immediately notice something is wrong. Put as many colors as possible and it makes it easier for me to spot any mistake. Although I can understand that more than a few colors can be distracting to some people.
As for "everyone does it wrong", and in particular wtt the Christmas tree effect, I find Kate's and IDEA's default color themes quite well designed and balanced, and where each sub expression start and end.
I do find light themes far more readable, and only use dark themes under very bad lighting conditions where a white background would hurt the eyes even at minimal screen brightness.
Bonus topic: in the Christmas tree screenshots, you can notice that parentheses are of different colors. This creates a visual mess but I do activate this option in Kate anyway because it is very useful to quickly check that the parentheses are balanc
It's less necessary when you have syntax checking though, because the editor will put a red background or draw squiggles.
Agree with the premise, but I built a theme with a different interpretation: https://marketplace.visualstudio.com/items?itemName=narenran...
The primary difference is that my theme has an underlying assumption that colors have semantic meaning that we all implicitly understand(red = bad, yellows/oranges are action-oriented etc). So instead of color = syntax, my theme semantically maps color = intent.
• Warm colors (orange/red) for actions — throw, return, await.
• Cool colors (blue/green) for definitions and values — function names, constants, variables.
• Muted neutrals for structure and noise — punctuation, keywords like var or const
This means comments are muted, contrary to the author's proposal - imo while they are important and helpful, they're secondary to the actual code
My primary design goal was that if you open a large file and squint at it, the flow should be immediately obvious (the flow colors stand out, if you see a bunch of blues it's calling a bunch of other functions etc)
(You can see screenshots in the link)
I love the concept of lexical differential highlighting [0] (discussed here [1]). It makes reading math so much easier, especially in dense code. However I don't know of any editor that implements a feature like this.
If you paste the following code into the example block in [0] you can see how useful this can be:
[0]: https://wordsandbuttons.online/lexical_differential_highligh...[1]: https://news.ycombinator.com/item?id=20414528
Keywords should definitely be highlighted. It's part of the structure of the code. Being highlighted makes it very quick to distinguish between keywords and variables and helps readability by making them easier to skim over and jump to. Maybe they could be the same color as punctuation, if number of colors is a problem.
Agree.
I also like minimal themes (and light mode!) but keywords are precicesly the thing I want highlighted. The "Visual Studio(Light)" theme in VSCode gets it pretty close to what I want but still has some inconsitencies that bug me but I haven't bothered making my own to fix them yet. It primarily just highlights keywords, comments, strings.
But then you can have something like public async Task<byte[]> SomeMethod(DateTime date, int someNumber) and int is highlighted but DateTime isn't...
I must just be weird. I prefer light themes.
I want all the colors, including "semantic highlighting", that is, each variable scope getting its own color.
I think the difference between highlighted colors, rather than the specific colors themselves, is what helps me parse code.
I like the dark color-scheme because the light color-schemes look like a lighthouse has been built on my desktop; it is an affront to my senses and burns my eyeballs.
I have no idea where I got it, but I have a quick JavaScript bookmarklet that darkens any page for me in an instant. I love it. And I, unfortunately, have to use it every time here on Hacker News.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
javascript: (()=>{var e="quick-and-dirty-dark-theme",d=document,i=d.getElementById(e);if(i)d.body.removeChild(i);else{var r=d.createElement("style");r.id=e,r.innerHTML="html, img, video, iframe { background: #fff;%20filter:%20invert(0.9)%20}%22,d.body.appendChild(r)}})();
> Most languages don’t distinguish between those, so there’s not much you can do syntax-wise. Sometimes there’s a convention (e.g. -- vs /* */ in SQL), then use it!
I do this in C to: /* */ for explanation, // for temporary disabled.
Are we sure this guy isn't trolling us? The advice about theming while using a yellow-on-black blog format, the "dark mode" toggle which makes the whole page black except for a spotlight focused on the mouse cursor... I'm not sure.
> Can you see it? I misspelled return for retunr and its color switched from red to purple.
That's not what syntax highlighting is for though.
That's falls under diagnostics. A big red squiggly line. The honest test would be to add that in both cases.
They’re not talking about the squiggly line. The word return/retunr gets highlighted in slightly different colors based on whether the highlighter is picking it up as a keyword or a variable name, but in the scheme the colors are similar.
But their argument is based on the underlying assumption that it's the responsibility of the syntax highlighter to tell you when you've made a typo.
I am presenting an argument against this - and stating it's the responsibility of _diagnostics_ to tell you when you've made a typo, not syntax highlighting.
I would add that no highlighting would be applied to this mistyped word as it would not be recognised as a variable or a keyword. This may depend on the way syntax highlighting is handled. A common solution like treesitter would sus out that no variable with the name retunr exists, probably causing the mythical base colour to be applied, heh. That is arguably a big highlight in a colourscheme that rarely uses its base colour.
I thought that the judicious use of colors would be universally regarded as sound advice [1]. But again, you can never get an online forum to reach a consensus on anything.
[1]: https://duckduckgo.com/?q=use+colors+judiciously
I like having the identifiers of function/method calls being a distinguishable colour, because when looking at an overall section of code, they are the 'wormholes' to other code, and so one of the most useful things to be able to pick out instantly at a glance.
But I agree with the author that if little to nothing ends up being given the base text colour (e.g. white or black) then the design is an unthinking one (less of a design process, more of a box-ticking exercise to assign a unique colour to everything that can possibly have one).
Nowadays "syntax highlighting" acutally means "syntax colorization" more. It's purpose is not just to mark specific tokens/lexemes/phrases (as in compiler principles), but to differentiate between them. Making something "stand out" is no longer the goal No.1. Human minds are not automata, so colorization actually helps a lot in parsing and preprocessing the text beforehand.
It's also pretty easy to take a theme you like and make tweaks. I have a local VS Code "extension" which is my custom color theme (never bothered to publish it).
1. I find it pretty suspect you intentionally don't use the default syntax highlighting in vscode, the editor you're using, as your baseline. Many of your comments just wouldn't hold nearly as much water if you did.
2. having keywords vs variable names vs functions be different colors helps you find misspellings, not the other way around. But that's almost beside the point, because it's your linter/intellisense/error checker's job to let you know when you have an obvious syntax error. You're also taking this as if you've just discovered this code block in the ether and have to debug it, rather that the reality that if you had actually been the author, you would have immediately noticed it, even without red squiggles, because it would be immediately obvious when you type it that it doesn't highlight as a keyword. Human brains are hardwired for pattern recognition, one could even argue it's the only thing the human brain is even good at.
3. I'm not sure where the notion of comments being grey is "tradition", but in practically every editor I've used, the default color for comments is a pretty easy to pick out green. Comments usually stick out like a sore thumb, in fact, as they typically don't share their color with any other syntax. Again, this points to you specifically picking out a non-default theme to make your points against.
4. "... gets so bad you can't see the base color" this isn't so much a thing, rather, the base color just isn't white. Which is because most people would agree that pure white on black is not pleasant to look at for long periods of time. There's a reason you don't see many dark mode highlighters use white. Again, default for vscode is a pleasant light blue. Plenty of contrast, but not so harsh it strains your eyes.
5. This is the most psychological, and subjective one, but plain, unhighlighted text just doesn't look like code. It looks like plaintext. Because plaintext is unstructured. Syntax highlighting brings out (highlights) the inherent structure of code. And that's kind of the entire point; it's there to show the structure. It may help you spot a typo, but that's not why it's there. That's an incidental perk. It's there because our brains are really good at pattern recognition, and having syntax follow a predictable color scheme taps in to that pattern recognition.
I'd say way more damage occurs when people neglect warnings and errors.
Like literally IDE not just highlights, it underscores a problem in red/yellow, puts a marker on the left of line, and on the right at the scrollbar as well. Also marks the whole file tab and file name on project tree. Gives a warning when user creates a commit.
Still, many, too many programmers don't care to either fix or silence it.
To each their own. If anything I tend to go farther, like using different tints for async vs sync functions in python and gdscript.
What'd be nice would be easier customization of these rules in your ide, like quick email rule creation in Outlook. Select what you want to alter, the rule modal shows you a couple options for targeting, then you can apply whatever highlighting you want.
Interesting post.
Just like everyone else, I disagree on some aspects.
One has not been brought up. So here's goes:
My first reaction to the highlighting of the literals (strings, numbers, etc) was:
"This is wrong! Who cares about the exact value here? I want to understand the program flow!"
But thinking about it a bit more, this is actually a deficiency in the code itself, not the highlighting:
It's magic numbers! And they get highlighted for you.
I seem to be the only person here who prefers the author’s approach!
The combination of adhd and colorblindness seems to make most multicolor displays just visual snow to me. It’s like looking at one of those magic eye pictures. I struggle with foreground/background in both vision and hearing, and it took quite a long time to realize others don’t process like that.
Here's an idea that hopefully will inspire something. You could use major color differences for large semantic differences (numeric literal vs. comment), midrange color differences for intermediate semantic differences (function call vs. local variable) and small color differences for small semantic differences (local variable vs. class member).
I recently switched from PyCharm to VSCode and the feature I miss the most is the bold yellow highlight of the symbol under the caret that was the only custom config I had in PyCharm. VSCode only allows a weak «box» around it which I struggle to see when scanning code quickly and I haven’t managed to find a good solution.
Good point.
If is not highlighting structure then is failing to do the pre-optimization that helps your organic parser do that.
The "matter of taste" part can come after the "matter of structure" was adequately elevating the right categories of elements to each level, hence inviting to receive the required attention.
Finally I understand why Tsoding uses a plain color theme.
This is a really insightful post. I created a Vim color scheme that uses even fewer colors than his but I didn’t realize that you might want to express nesting through varying lightness levels. I also didn’t realize that using HSLuv and making all lightness uniform might actually hurt the scheme.
Related (from recent posts on HN): https://ruudvanasseldonk.com/2025/abstraction-not-syntax
I really like the idea of color representing scope and relatedness, rather than syntax.
I thought this was going to be about highlighting based on symbol type or identity instead of language syntax, like all instances of the same type or function or variable would be the same unique color. I think I saw a vscode extension for that a long time ago, does anyone use it?
I have used Tao theme in Emacs along with rainbow identifiers for over a decade now (on light mode) and I personally prefer a less colorful palette on my text editor. Makes a nice contrast with my eboy tokyo/San Francisco backgrounds which I also love dearly.
Aside from the rest of the (interesting!) nuanced discussion going on the comments here -- I really like his idea towards the bottom of combining the colors for numbers and strings into one.
They're both constants, so yeah, they should be!
Needs examples of what a few common editors and IDEs use by default to make the case of what they do well and don't, at least in conjunction with the title. What does RustRover do well? Poorly? What about Github in-browser/ VsCode with its deafult Python config?
I agree with the over highlighted examples being over highlighted but the author's preferred schemes are even worse, especially with different background colors. I guess everyone has their own opinion and thankfully there are plenty of options.
I'm surprised not to see any comments about rainbow brackets for the Lisp family of languages. I just started in a non-Emacs environment to avoid learning two things, but colourful brackets have made the paradigm shift a lot easier for me.
If you’re not using Monokai classic then you’re definitely getting syntax highlighting wrong
> Here’s a quick test. Try to find the function definition here
This is only an issue for websites and they generally have short code snippets anyway. I’ve been using the same theme in my editor for the last 10 years so it is much more useful there.
I don’t think the value is for some things to stand out and other things to fade back.
It’s for color to label the type (or other high-level semantic characteristic) of different tokens.
> What’s the base text color here
Why should there be a “base text color” at all?
I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.
personally, the golang highlighting is nice.
- dark blue: keywords (var, nil)
- light blue: variables (defines the scope you're looking at)
- blue-green: types (bool, string, your custom thing, the kind of the variables)
- dark green: comments
- yellow: functions/methods (jumping to another section)
- orange: strings (not variables, so static things here!)
- if/braces/parens/select/switch/defer/go: purple (control logic)
My scheme is a bit modest. Comments, keywords, and string literals are highlighted. The rest is just black on white. I tend to agree that less is more.
Website with background-color: #FDDB29 talking about color choices.
Irony at its best.
I guess I'm one of the color-loving fools, but I found the "look how bad it is" examples far easier to read than the alterative.
The white color literally has the best contrast on the dark theme and for me stands out the most. So this achieved the opposite (for me)
my favourite has always been Visual C++ 2005, with very simple rules:
- blue for keywords and integer constants
- red for strings and characters
- green for comments
- black for everything else
I agree with everything the author said here, but unfortunately no mention at all of semantic highlighting! This is the killer feature for me and I literally cannot do without it.
My most unpopular opinion about syntax highlighting is that comments should be displayed in a proportional serif font.
(And of course white background always. Dark mode is depressing.)
Your preference for light and dark mode doesnt change with the ambient light?
Im always surprised by the number of people who will delcare one absolutely better than the other without consideration for this factor. Sure, people have some general preferences, but I thnk it's 90% about the ambient light.
If it's pitch black most people will prefer dark and if it's bright daylight people will prefer light.
F.lux / Redshift / Gammastep exist. On sunset, my screen becomes much darker and tinted yellowish / reddish. Then white backgrounds look fine, and I happily continue using my light color themes late into the night. Also, bias lighting on the wall behind the monitor helps my eyes avoid strain.
Kinda making my point. Sure, technically you are still using the same light theme. But you darken it. Point being the ambient light is a major factor.
Every once in a while I'm building a table in comments and then spacing matters. Most of the time I don't care.
> (And of course white background always. Dark mode is depressing.)
Twice during the last couple of years, I’ve done this poll online:
... and, each time, “Match my chosen mode” won with well over 75% of the votes (about 150–200 total votes in each case). Accordingly, I’ve styled my site’s code blocks to handle both dark- and light-mode viewing. I also provide a switch that enables one to toggle back and forth just in case the chosen system mode doesn’t match how one wants to view code blocks (e.g., some people prefer to see code blocks in dark mode even if they’re otherwise using light mode).I’d be good with a hot-swap between markdown and not-markdown for comments, too, honestly.
After a couple of years working in Smalltalk, I’ve acquired the hot take that all the code should be in a proportional font. Admittedly it doesn’t work quite as well for brace syntax languages, but in Smalltalk and Python it’s great.
This means all code should be prose and lose subtle spatial arrangements that are easy to add with monospace.
It works better if you're using Elastic Tabstops.
Vim already does it the way the article says is right, by default.
Author finds out they're colour blind.
I was prepared to hate this article based on the clickbaity headline "...everyone is getting syntax highlighting wrong". But I agree with the premise, and I find his proposed scheme a lot better than some of the most popular colour schemes that I see online.
But I use the Nord colour scheme in VS Code, and it appears to follow the same principles as what the author proposes. There are only a few colours, with a lot of the code remaining in the base colour. Also, Python comments starting with `#` are dimmed, but comments in triple-quote blocks are highlighted. The funny thing is that I had never even noticed this, it just seemed to be intuitive.
In my experience I have never once thought about what color means what, but if the colors are wrong I can "sense" that something is broken. It almost becomes a second sense, the patterns are recognized somewhere deep in my mammal brain
You might not skim for `retrun`, but if you're used to it turning purple when you type and it doesn't that time, you might notice.
> There's no [...] good-looking "dark teal".
> light [themes] can't look good. Science
Sorry, but 'my preference is x. Therefore y. Science' is not how any of this works. I get that it's a joke, but considering light themes are objectively superior (c. ref. <https://journals.sagepub.com/doi/abs/10.1177/154193121360181...>), I take umbrage.
The most important thing is familiarity.
I mean, any of those would work, but the one that works best is the one you're used to.
The brain is great at learning patterns, I'm extremely used to IntelliJ's classic theme (light) with Firacode with ligatures.
But that's me, I've been daily driving that for years, so stuff just pops up at me.
I like semantic highlights (i.e. something is static or a field, or whatever) rather than pure syntactic ones, but what matters most to me is stability.
If it changes for no reason, it's jarring and takes a while to get used to it again.
I've done a lot of experiments. Most turned out wonderful ways to ruin readability. (I combine those to highlight a single line of code in an article to troll the reader)
It is a huge problem that we are so used to what we have. I can barely make sense of the examples in the article.
I think it calls for actual research where we collectively catalog the approaches, experiment (on humans) and attempt to have conclusions about them.
What surprised me most in the experiments is that giving each different variable and each function call a different color makes scanning over the code much easier.(function declaration and call the same color)
Also a very successful experiment was to color the opening and closing brackets the same color and use a different one for each level of nesting.
One that I failed to code/design properly but looked very promising was to faintly color the background of each level of nesting so that the color gets more visible the deeper you go. It makes the hot spots jump out.
Probably the funniest was to have basic html tags in comments (like headings, pictures and videos) then define a css at the top of the code.
I like examples with more colors? For me, colors serve as a sort of a token highlighter. It's easy to see the different kinds of tokens.
I’m the same way. The squiggly lines would tell me if `return` is spelled wrong more than a slightly off color would.
But colors help me separate “this whole thing is a string” from “this is a string but with code inside it”. Comments being gray doesn’t make them less visible for me, just visibly different which is all I’m looking for.
99% of the colors don’t actually matter to me. It’s the distinguishing of conceptual elements that are adjacent to each other that matters more to me.
I get the impression you did not follow through with the whole article, as that is the point being made. In the colorful examples, variable declaration, access, parameters, method calls and event the mistyped return have similar colors, making the token types indistinguishable. There are also way too many colors to be able to recall anything.
Removing color from variables is a bit too far for me though, I expect the declaration and any subsequent access to be visually consistent.
What kills articles like this for me is the (implied) and click-baity "I'm the only one doing it right". I stopped reading right then.
And yet here we are in VSCode, still completely unhinged, not letting us have background colors in themes at all.
Apparently it's too technically complex :D (their words in the open GH issue, not mine)
Another “everyone’s doing this highly subjective thing wrong” post. Why do you think there are so many color schemes, my guy? Pick the one that works for you and move along.
I find that i adapt to color schemes pretty quickly and subconsciously. Using the same theme and going from JavaScript to Java, for example, you'll see a lot of different colors on average--lots more class names in Java, for example, so lots more red, in my case. But to me it's less about what color means what, and more about the patterns. If other strings are yellow and mine isn't, problem. If the name I'm using doesn't match the function argument I'm expecting to use, maybe i need a `this.`.
It does seem self evidently bad to use the same color for multiple different things. I feel like bold and italic text can be helpful there, like maybe you reuse a color but change the style depending on context.
Honestly i think when the majority of the content is one color, my brain just writes it off as one big block of stuff to skim over, whereas everything with it's own color actually makes more sense to me.
And yeah, i didn't spot the "retunr", but if i were typing it in real time and the word didn't match my mental map for "return," i probably would still notice.
In my experience low-color guys were either uber-programmer greybeards or fucking morons cargo-culting uber-programmer greybeards. Most bimodal property ever. You don't find that with vim bindings etc.
I wonder which software engineer traits are like this. Maybe everything that it's kind of low-friction to do. If you had a CRT screen you're probably a details oriented person. If you've got conky running you're from the time when you needed to watch those things or you're a moron cargo culting that.
hard disagree