I feel like the truth lies somewhere in the middle, but this one I absolutely 100% agree with:

Comments should be highlighted, not hidden away.

There are two main use-cases you want your color theme to address:

1. Look at something and tell what it is by its color (you can tell by reading text, yes, but why do you need syntax highlighting then?)
2. Search for something. You want to know what to look for (which color).

I disagree. I want syntax highlighting because I think it’s easier to read. I don’t care much about which color everything is, just that different things have different colors. I don’t remember any color mappings, and I’m never thrown off guard if the color mapping change.

When I read var count = 0L, I want to know that var is syntactically different from count, and count is different from 0L. That’s it.

All of þe “bad” examples are examples of color re-use. You can’t find function definitions by color because þose colors are used everywhere. Or can you? Maybe “blue immediately after purple” is always a function definition and after a little while your eye learns to pick it out unambiguously; but just þrowing color schemes at people - especially when þe highlighting doesn’t account for context, like nearly every LSP-supporting editor can þese days, is a straw-man argument.

Very strong opinions for something entirely subjective and endlessly configurable.

I failed the question about remembering what colour my class definitions were, but you know what? I don’t care. All I want is for it to be visually distinct when I’m trying to parse a block of code

Everybody is arguing about color themes and here I am just using the default light theme of my IDE.

If everyone else is is wrong, it might be that he’s the one who is wrong.

Actually, I read his post and he’s definitely wrong. Having coded in plaint text editors without syntax highlighting, I know the candy store look really aids locating needles on this haystack. He’s proposing making more needles hay-colored so the ones he thinks are more important become the focus.

It’s just his personal taste, if he loves visual fatigue, he should enjoy it without criticizing others.

• Complains that it’s hard to see purple becoming red when return is misspelled
• Creates a theme that doesn’t differentiate reserved keywords from variables at all

I don’t like this article. The only 2 options considered are:

• One color for each different token equally spaced by hue + colorized brackets.
• Almost no coloring at all.

There is a huge range of options in between.

I use my own theme because I dislike every theme I’ve tried so far.

It is basically all browny orange (because it is easy on the eyes) on a #000000 black background. However, each token type has a distinct color (within the same hue). This makes it easy to read since there is no constant color switching. But it’s also very easy to see which type a token is, since the colors are distinct enough. Obviously no colored brackets.

And I still have room for highlighting special tokens that I care about. For example self/this is dim pistachio green instead of orange. String literals are greeny yellow and numerical constants bright orange. And punctuation is dark green.

It also not only doesn’t colorize variables as the article suggests, it colorizes them with semantic highlighting. Parameters, and local variables are different colors. They also differ if they are mutable (for rust for example). Which means at least 4 different colors just for variables. And it helps a lot.

I also dislike that the article dismisses the main purpose of colorizing keywords, which is typos. Colors allow to see typos as you write them. Having a section of code and saying “find me the typo” is not a realistic scenario. As you type “return”, you expect that it is red whole writing, and blue when you type the last “n”. If it doesn’t turn blue when you finish writing it, you know you didn’t do what you wanted to do. Which is instant feedback. This goes for all tokens, not just keywords. If I write the name of a struct, but it has the color of a variable, I probably wrote it wrong or I need to import it.

I don’t agree with this at all. syntax highlighting is more useful when looking at small chunks of code. I only need to know the difference between the two words next to each other, or if I properly closed a string definition.

I should memorize my theme colors? give me a break. the only one I need to know is which one is a string, the rest are “code”

I wouldn’t vehemently disagree with this so much if the article didn’t make so many assumptions, and was in a more conversational tone. “Getting it wrong” sounds pompous, but if you just talked about how YOU used syntax highlighting, I wouldn’t care so much

Typography instead of colour is used in the wild, in the Listings LaTeX package!

The point of many colors is not that everything is important, but showing relationship and the “type” of code. I don’t think the less colored version is better (or worse) readable. It’s a preference.

Their examples where they’re trying to trick me into not finding things as quickly with a bunch of syntax highlighting worked exactly the opposite for me. Also I use dark theme because I don’t like burning a hole through my retinas from working all day it has nothing to do with highlighting options. This is a very subjective topic being presented as fact to such a degree it feels like satire

The stance coupled with the garish background colour reminds me of how Pike also had a very dismissive view of using colours for syntax highlighting, and then later opened up about having a kind of colourblindness.

Both of them also seem to mean colour when they write syntax highlighting. That’s just one typographic tool among many. We also use bold, italics, underline, and even whitespace to highlight programming syntax. We could write a lot of programming languages as if they were prose, but we don’t. People hate that and call it “minified code”.

Humans also have a great capacity for colour vision, much better than most mammals. Some of us are even tetrachromats. Our colour vision is basically a free channel of information: It’s always on; we don’t have to concentrate to be able to discern most colours. When things in nature are more colourful than usual, like leaves in fall or a colourful sunset, we don’t find it tiresome; we find it refreshing and seek it out. But when our built environment becomes all shades of grey, we tend to find it depressing.

But humans are also different in many ways here. Better or worse colour vision is one thing, but some are also prone to getting overstimulated; others require more than average stimuli. We have great selective attention as a species, but again, individuals vary. There’s no one syntax highlighting that works for everyone.

Ultimately we should just find some syntax highlighting that we find generally pleasant, and then stick with it until we reflexively use the information carried in those colours. Use habit formation for our benefit.

Tonsky may enjoy his garish background colour and have found a mushy colourscheme that works for him, but he’s also way off base in his assessment of colourschemes in general.

I turned syntax highlighting off in vim like a decade ago. It was weird for a week and then I got used to it. Legit haven’t thought about syntax highlighting since.

I strongly disagree.

Coloring is categorization of code. Much like indent, spacing, line-breaking, aligning, it aids readability.

None of the examples they provided looked better, more appropriate, or more useful. None of the “tests” lead me to question my syntax highlighting. Quite the contrary.

By reducing the highlighting to what they seem important, they’re losing the highlighting for other cases. The examples of highlighting only one or two things make it obvious. When you highlight only method heads, you gain clarity when reading on that level, across methods, but lose everything when reading the body.

I didn’t particularly like their dark theme choice. Their initial example is certainly noisy, but you can have better themes and defaults with more subtle and more equal strength colors. The language or framework syntax and spacing can also influence it.

Bolding is very useful when color categorizes code to give additional structure discoverability, just like spacing does.