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.
Did you spot the error with
return?And the theme the author used was a bit disingenuous. Like, why was audio two different colors? One for the declaration and one as the call member? Like of course it’s useless like that. I think there’s a happy medium between the two but I’m like you. If I’m coding and I need to find a variable I look at what color it is and then search for that color. If I need to find function defs I do the same. Same for everything.
I didn’t, but a linter or some other tool like that is much better suited for catching errors like that.
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?