Needs examples of what a few common editors and IDEs use by default to make the case of what they do well and don't, at least in conjunction with the title. What does RustRover do well? Poorly? What about Github in-browser/ VsCode with its deafult Python config?
It's also pretty easy to take a theme you like and make tweaks. I have a local VS Code "extension" which is my custom color theme (never bothered to publish it).
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.
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.
> 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.
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.
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.
> If everything is highlighted, nothing is highlighted.
Somewhat related, I got used to turning off syntax highlighting for some coding sessions.
It started when I was using vim to edit large data files and syntax highlighting there was buggy.
Later, I worked with large react files, where with each JSX block the latency and highlighting reliability was getting worse. So I turned it off too and I was surprised that I didn’t see a big difference in readability after that.
I’d still use syntax highlighting for backend work. But I don’t mind looking at large html files or react prototypes sans highlighting.
This is a really insightful post. I created a Vim color scheme that uses even fewer colors than his but I didn’t realize that you might want to express nesting through varying lightness levels. I also didn’t realize that using HSLuv and making all lightness uniform might actually hurt the scheme.
I thought this was going to be about highlighting based on symbol type or identity instead of language syntax, like all instances of the same type or function or variable would be the same unique color. I think I saw a vscode extension for that a long time ago, does anyone use it?
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.
Here's an idea that hopefully will inspire something. You could use major color differences for large semantic differences (numeric literal vs. comment), midrange color differences for intermediate semantic differences (function call vs. local variable) and small color differences for small semantic differences (local variable vs. class member).
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.
I got started with Notepad on Windows, did that for almost a decade before switching to Linux and learning how to use vim. Definitely prefer the rainbow highlighting to going back to anything close to that.
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.
> 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.
No... the best way is to use the same color for all occurrences of the same identifier. So, on the last example, all instances of say "audio" should be of the same color, and those of "filename" of another color.
I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.
82 comments
[ 3.0 ms ] story [ 76.9 ms ] threadI really like the idea of color representing scope and relatedness, rather than syntax.
(And of course white background always. Dark mode is depressing.)
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.
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.
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.
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.
Somewhat related, I got used to turning off syntax highlighting for some coding sessions.
It started when I was using vim to edit large data files and syntax highlighting there was buggy.
Later, I worked with large react files, where with each JSX block the latency and highlighting reliability was getting worse. So I turned it off too and I was surprised that I didn’t see a big difference in readability after that.
I’d still use syntax highlighting for backend work. But I don’t mind looking at large html files or react prototypes sans highlighting.
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.
I got started with Notepad on Windows, did that for almost a decade before switching to Linux and learning how to use vim. Definitely prefer the rainbow highlighting to going back to anything close to that.
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.
Original idea from here: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e
One impl for Emacs: https://github.com/ankurdave/color-identifiers-mode
I still admire you Niki.
Apparently it's too technically complex :D (their words in the open GH issue, not mine)