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.