Context Coloring | Hacker News Reader

Context Coloring

crockford.com

21 pointsthisisblurry20 comments

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

Agreed, and it is indeed possible to have "context coloring" with normal, useful syntax highlighting alongside it - subtly lighten or darken the background color when going down a scope level into a nested function etc.

A lot of code editors and IDEs already have folding indicators and indent guide lines which provide the sort of "context coloring" that is demonstrated in the article. (VS Code's language-server based contextual folding, especially.) There are extensions to add colors to those guide lines and fold indicators, but it probably says something about how generally useful it may be in that code editors don't default to that behavior.

(For instance, in JS I've come to prefer to un-nest structures as much as possible and the provided example hit some of my code smell receptors that I would refactor it and un-nest most of it, but that's my aesthetic preference here.)

This is especially true for languages with a lot of syntactic cruft. What immediately stands out is the equal focus given to the less important characters like brackets and braces.

Still, it's a novel idea.

Hugely agree. Crockford seems to assume that syntax coloring is there to be a cognitive aid for people who don't understand how to distinguish literals and operators. It's surely not, it's there to be a visual aid that lets your eye jump directly to the part of the code it's looking for.

As such the article just reads like a Chesterton's fence - "let's get rid of this thing because I don't see the use of it".

The only study I could find on the topic seems to support that syntax highlighting makes it easier to read and understand code regardless of programming experience. Calling it "training wheels" seems to be a completely useless brag, or perhaps the author has synesthesia - effectively performing the syntax highlighting in their head?

[0] http://www.ppig.org/library/paper/impact-syntax-colouring-pr...

I agree, but in the same way, if the code is structured well in a visual way it could be as easy to read without syntax highlighting. I guess it all depends on how well you know the language and the code base. I guess I've got into a routine for a long time now and happily have syntax highlighting turned off in Vim.

It's especially silly for someone like Crockford to say this, whose primary claim to fame is his belief that JavaScript is too hard for people to understand. "JavaScript: the Good Parts" is like training wheels or school paste.

It's also a quick visual way to ensure that you and the computer agree on what the code parses as. You might think that's a keyword, but maybe a few screenfuls up you didn't escape something right and you're still in a string constant. Automatic indentation can help but... well, isn't that kind of childish, too?

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.

Another idea... what about the IDE inserting a subscript or superscript after a variable to indicate how many contexts removed from the current context it was defined? Or possibly to indicate type information.

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

We can do better.

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 agree with most of your comment, however I don’t see how indentation would help highlight the scope of the variables when they’re used as shown in his example.

GP said indentation markers - typically vertical lines rendered on the background on every line at every indentation level before the first character of code.

Like this, (but the | is not in the source):

    def fun()
    |    return 'blah'

    class Foo:
    |    def __init__(self):
    |    |    return None

Often it'll be a more subtle colour than the code so it's less visually heavy than presented here. In vim I have it only shown in normal mode, to avoid confusion while editing.

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?

Reply on news.ycombinator.com