Getting syntax highlighting wrong

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

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.

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

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.

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

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.

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

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.

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.