Context Coloring (opens in new tab)

> Syntax coloring isn't useless, it is childish, like training wheels or school paste

Not as childish as writing a blog post bragging about how you don't need syntax highlighting to code.

In all seriousness, though: yes, after a while, you don't usually need it. But it's an immediate visual confirmation that I used the wrong type of quote for a string literal, or that I forgot my `def` statement before a python function. Unless you literally never make these errors (or the myriad other little errors that can be caught this way), syntax-aware editor tools like syntax highlighting or auto-indent will save you time by alerting you of your error promptly and letting you fix it without getting distracted. Nothing beats having the whole page suddenly look the wrong color to get your attention.

I actually can't think of a better way to avoid the class of errors that highlighting instantly exposes.

[edit] I do agree with Crockford that extra types of highlighting/formatting for readability can be great, including context-based coloring; emacs's rainbow parens does something similar based on enclosing parentheses, though the interior of the parentheses is still highlighted in the standard way.

> Syntax coloring isn't useless, it is childish, like training wheels or school paste

Disagree with the sentiment behind this. Just because you can read code without syntax highlighting doesn't mean it's useless, or only for programmers who need training wheels. It makes scanning code by eye so much easier, in the way that capital letters make reading this blog post easier.

It's so long since I've written any code without syntax colouring, I don't even know if it can be turned off in my main GUI tools (IntelliJ & VS Code). When I've occasionally seen code in notepad or an unconfigured vi, it looks like an undifferentiated mess. Which isn't to say it wouldn't be a useful or interesting exercise to try without it for a while. What we're habituated to isn't always a good guide for how to proceed.

Colouring by nesting level might be useful in javascript, but strikes me as a poor idea in the other languages I'm using right now (Java, Go, Rust). Nesting is often accidental complexity, and can usually be reduced with a bit of thought. For that reason I'm happy for deep nesting to be visually confusing - it's a useful extra motivator.

(Come to think of it, with async/await, one of the main cause sof deep nesting in javascript can be minimised also).

We have indentation for context, the only thing this is really bringing to the table is highlighting variables of the outer context when used inside the inner context. But that only seems necessary because the example is awful code, cramming everything into the return statement. There is also an awful lot of brown there that would have been clearer with syntax highlighting, so even in this contrived example it's a mixed result.

And if syntax highlighting is training wheels and context colouring is better, does that make it your dad holding the back of the seat?

What about context coloring the background color and syntax coloring the code? Which maps well conceptually as well.

> I think we can better.

What kind of sentence is that? Maybe it's saying we can better perform some activity that was mentioned in the previous sentence? Let's look at that:

> Syntax coloring is very popular, especially with coders who still struggle with basic syntax.

So, "I think we can better...struggle?" Hmmm.

Perhaps the Crock would have done better with some English syntax highlighting such as the kind commonly found used in spelling and grammar checkers.

I think context coloring applied to the background would make more sense. In my opinion, the author misunderstood what makes syntax coloring useful. I can only speak from a personal point of view, but for me, syntax coloring is not about hinting at syntax or helping me understand it's about improving visual search speed. When I crunch through existing code, looking for "something", there are multiple things going on. Firstly, I'm not looking for specific implementation text, I'm looking for a concept, an idea. So I'm not actually reading the letters or forming words, I'm not even looking that much at the length of the words. I'm looking at the shape much more, and at the shape level, syntax coloring gives a nice hint to what KIND of shape I'm looking at. When I've found an interesting shape, I'll scan for the concept, I still don't read everything, maybe a few function names, which are super quick to find, partly because the syntax highlighting makes them stand out, so I can scan to figure out if I'm at the interesting part yet. When I think I am, I'll start executing code: I'm not checking for correctness at this point, this is not a review, I assume it works, so I ignore much everything that's not function or variable names, syntax coloring is instrumental in this too, as it allows me to ignore by color. When I'm executing fully, the types and other details fly into my mind automatically, partly due to syntax coloring.

If I were to turn the table on the author, I'd say he has a problem keeping track of simple scoping and tries to cope.. I would suggest he turn on the indentation markers in his editor, that's what he wants. Though he should be aware that in some languages, context is much more complex than indentation, and that's the kind that'd be interesting to highlight, for example, by changing background color.

--

Ps, I wrote my first many klocs in windows notepad, so it's not like I was brought up on syntax highlighting and can't get past it, it's just that I've learnt to take advantage of a richer environment (vim).

I'm colourblind (protanopia I believe), the context colouring doesn't appear to work for me.

I can use syntax highlighting to snap eyes to the correct pattern I'm looking for, I can't really discern the value in large coloured blocks of text though. I can already work out what part of code that is by the rough shape of the block before I even start reading it, why would you need to colour it in?