> 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.

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.

> 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'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 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.

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.

> 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.

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.

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 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.

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.

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.

> 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.

> 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.

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)

"In matters of taste, there can be no dispute." -dad

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)

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;
    }

[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.

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!

> 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.

I thought we all agreed that Turbo Pascal/C had the best color scheme?

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)}})();

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.

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).

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.

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).

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.

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.

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).

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.

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.

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'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.

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.

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?

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.

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?

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’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.

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.

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 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 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.

Author finds out they're colour blind.

Vim already does it the way the article says is right, by default.

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>*/

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.

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

> 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.

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.)

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.

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.

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)

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