Programming

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.

I guess I’m one of the few here who uses pretty much the same approach with 4 colors as the author, with even another twist. I’m not saying I followed the same train of thought to come to this conclusion, but the names of my constants and functions are black, strings are green, and numbers are blue. The keywords and punctuation are gray to be less visible, not unlike in Python.

The added twist is a nod in the direction of people saying the white background burns their retinas, but there are more background colors than blue and white. I chose a calm light-green one, which I also use whenever I’m reading texts. It’s not exactly the combination with the most points in the scientific readability research, but I remember that the dark background lost that competition.

I attribute to these choices the fact that I notice many more typos in the code of my colleagues than they do in mine.

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

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.

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.

• 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

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?

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

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

The article is offering a strong opinion, which might be just because you get more engagement that way. I'm not offended by that, it's just how the internet and media in general works.

The thoughts about approaching syntax highlighting differently do intrigue me. I'm definitely playing around with my color theme in the coming days to see if something different suits me better.

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

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.

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

Hm don't agree with their choices, but interesting to read through the thought process. The more colorful theme seems more useful to me, even if I can't remember the colors I use. I think its a VS code standard theme. I never really cared about customizing everything in general, I just keep what I found useful around.

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?

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.

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.

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.

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

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.