• 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

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

Per statistics, 70% of developers prefer dark themes. Being in the other 30%, that question always puzzled me. Why?

Have you tried asking any of them?

And I think I have an answer. Here’s a typical dark theme: [...] and here’s a light one: [...] On the latter one, colors are way less vibrant.

Does the author not understand that a lot of us code in darker environments where the light background of most light themes either sears our retinas or forces us to turn the monitor brightness so far down that everything becomes a shade of grey?

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

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.

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.

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.

I find it much easier to find the function definitions when the word function is a different color than most of the surrounding text.

if the author meant "find a specific function def according to it's name or role" then I could at least appreciate the perspective. As it stands, I can't help but notice that their supposed "better highlighting for finding defs" example is not using the same source code: the preceding anonymous immediately-invoked function that englobes the entire first code block/sample is now off-screen and the code blurb itself is different...

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.

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.

Our eyes are way more sensitive to differences in lightness than in color, and we should use it, not try to negate it.

I thought the center of our vision is more sensitive to color whereas the edges of our vision is more sensitive to light/dark?

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

In terms of syntax highlighting, something like flowistry seems more important to me than bike shedding the perfect static highlighting approach.

Agreed, generally. Most themes suck because they don't make reading things easier. They are overdone. Just compare plain vs. in readability, ignoring aesthetlics.

Except the comment part; important comments have TODO:, FIXME:, NOTE:, things like that and are highlighted specially.

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

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

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.

Finally, I am much more often interested in what I/the code is doing to a variable than how it is initially declared.

Overall, if this approach works better for the author than more power to them! Please stop affirming that everyone else is doing it wrong, especially when you seem content to speculate why we do things differently instead of at least mentioning some reasons we ourselves give for how we do things.

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.

If everything is highlighted, nothing is highlighted.

Kinda ironic given the whole site looks like someone attacked it with a highlighter.

Yeah, I don't agree with this blog post at all.

Color highlighting in code is fundamentally different than in standard text. In text, it means, "I'm important!" But in code, the purpose is to categorize. When I read code, this is important because everything is in a category and in a hierarchy. So I'll skim through all the things of one category until I find the block I'm looking for, then skim that block to find the next category of code.

And the they have other points like, "if you can't recite all the colors and what they mean, then I'm right." No you aren't? Within ten seconds of looking at some code in some editor, my brain creates the color/category mapping, and then I'm good for the whole time I'm working. Why would I memorize it?

The whole thing just reads like someone had an epiphany and is trying really hard to justify it.

Why are you sorry? Is it your fault?

I don't think my IDEs are quite as colourful as his. Did he choose a deliberately bad colour scheme to try to make a point?

He makes good points in the article but has a bright yellow website.

Strongly disagree with the author on this. Syntax highlighting for me is to be able to differentiate discrete parts of code rather than being able to quickly identify what is what. I don't rely on syntax highlighting for catching errors since linters/compilers are a much more appropriate tool for that. Their color scheme is far too bare bones that it feels like one step above writing code in notepad. I have to do more thinking to see what the code is doing in the "improved" color scheme where the "inferior" version I can mentally see each part is distinctly different from the other parts. Maybe if they didn't use such a clickbait title I would be less harsh.

I can see the point that too many program elements get too much color, but:

Suggesting to not color keywords and use a single color for the names of top-level elements at the same time simply doesn't mesh well.

I'm coloring keywords exactly because I do not want to invent a new color for each individual top-level element name or require backtracking from the (in his proposal) highlighted name to the (in his proposal) non-highlighted keyword preceding it.

Looking at the code example here I'd be open to have less things highlighted, but where to start? I guess parameter names, but apart from that?