I like the concept. I don't buy all the author's personal choices, though. I think the highlighting should serve 2 purposes: 1. help you parse the code, and 2.

I like the concept. I don't buy all the author's personal choices, though. I think the highlighting should serve 2 purposes: 1. help you parse the code, and 2. put more or less emphasis on some elements. Comments have a primary role when reading someone's code, so they deserve a distinguished color by virtue of point 2 above. Strings are sometimes difficult to parse correctly because the symbol to start them is the same to end them, so item 1 above applies. And variable definitions have the tendency of hiding in plain sight, despite being crucial to understand a piece of code, so they match both criteria 1 and 2. But numbers, booleans and constants can't be possibly mistaken for anything else, nor do they need to stand out more than the rest, so why highlighting them? Deemphasizing punctuation might be a good idea: I'd probably reserve the same treatment to some common boilerplates, too, like #include in C/C++, #[derive] in Rust, etc. Finally many languages make it hard to tell types and variables apart. Therefore I'd argue that types deserve their own coloring, obeying reason 1 above. To add a final nitpick, the two "use" statements in the example define two symbols, "FilterType" and "Error". I think only these two words should be highlighted in blue, not the rest of the hierarchy.