A case against syntax highlighting

Do you rely on syntax highlighting when developing software? If so, you may be shooting yourself in the foot. In this post, I will argue that syntax highlighting, while aesthetically seductive, moves focus from content to form, and discourages those who look at the code from trying to understand it.

An example of syntax highlighting.

Background

Syntax highlighting is a standard feature of most modern text editors and development environments. The basic idea is to exaggerate the visual difference between various syntactical elements, to make it easier for the programmer to distinguish between keywords, punctuation and variable names.

Why was syntax highlighting invented in the first place? Did the programmers get the syntax all mixed up when reading code, thinking that ")" was perhaps a variable name or even a preprocessor directive? Of course not. While reading computer programs is often difficult, the difficulty comes from the intricacies of the program, not from the syntax.

Legibility

Perhaps syntax highlighting was invented to speed up the reading process. Yes, that must have been it, highlighted code must be easier to read. After all, it has colours!

Well, no. One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it. Likewise, a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text. The natural flow of the text is broken, and it takes more brain effort to piece together the individual letters into words and semantics. Cognitively, the reading process becomes slightly less automatic and slightly more conscious; leaving less room in the conscious part of the mind for actually understanding the text.

Semantics are more important than syntax

Understanding is vital when reading code. Unlike novels or newspaper articles, where you can skim through a paragraph and learn the gist of it, software is inevitably full of complexities and important details that you just have to take the time to understand. To do that, you need to be looking at the code at the semantic level.

Syntax highlighting applied to fiction. It's easy to spot all the verbs, but why on Earth would you want to do that?

And even when the code is already well-known to them, most developers would rather come across (and fix) memory leaks, security holes and inefficient algorithms than mere syntax errors. Syntax errors will be found by the compiler anyway; the developers shouldn't waste time looking for them. But if syntax highlighting biases their minds towards the syntax of the code rather than its meaning, wouldn't they end up doing just that?

I'm not saying that developers are stupid. But since we all miss the occasional bug here and there — everybody makes mistakes — I think it would be a good idea to configure our tools to help us find them, rather than help us miss them.

An example of bypassing the learning curve: Training wheels.

Learning curve

Maybe syntax highlighting wasn't intended for experienced programmers. Maybe it was introduced in order to flatten the learning curve for newbies, much in the way that some misguided piano teachers put coloured stickers on the keys. I suppose the piano teachers do it to improve communication ("press the yellow key now!" rather than "play an F now!"), but do they honestly believe that children are unable to learn note names? They will have to, eventually, and then they will have to un-learn the colours.

The same phenomenon can be seen in user interface wizards. An advanced operation in, say, an image manipulation program is complex, and the complexity confuses new users. Enter the wizard dialogue box, which will skip or automate some of the steps, at the cost of flexibility. In the end, users only learn how to use the wizard, rather than the complex functionality itself, so the extra flexibility is lost. So you're not flattening the learning curve at all, you're bypassing it.

If you learn to write software in colour, you will probably find it difficult (or at least awkward) to look at the same code without colours, or even with a different colour scheme. Seen in that light, syntax highlighting is an educational dead end. It's like learning how to ride a bike with training wheels. You won't be able to ride a normal bike until you un-learn some of the techniques you've picked up along the way.

The exceptions

There are two cases in which syntax highlighting can actually contribute something. The first one concerns multi-line comments. If you're jumping around in a source code file, perhaps as part of an interactive search-and-replace operation, you might end up in the middle of a large block of commented-out code. You begin reading it as code, and after a while you run into an end-of-comment token, and realize that you've been reading a comment all along. In this case, rendering all comments in a different colour would have prevented the mistake.

On the other hand, that would be a short-sighted solution. Most people agree that commenting out code should be seen as a highly temporary debugging technique, and that the commented-out code must be removed or rewritten sooner or later. Changing its colour to get it out of sight would be like sweeping it under the rug.

The second case mainly concerns the C language. Accidentally writing "=" instead of "==" can result in a bug that is particularly hard to find, since you can sit and stare at it for a long time without actually seeing it. This is the only case I've found, where you would benefit from being able to focus on the syntactical level of the code, without paying too much attention to the semantic context. With syntax highlighting it would be possible to mark "=" and "==" in different colours. Yay! A good reason for implementing syntax highlighting! But — and at this point it probably won't surprise you — every colour scheme I've come across uses the same colour to highlight both "=" and "==".

Conclusions

Syntax highlighting doesn't improve legibility. It encourages you to skim through code rather than understand it. It makes you focus on syntax errors rather than real bugs, and it gets in the way of your learning. Arguably, it even encourages you to procrastinate the removal of commented-out code blocks. And current implementations of it fail to differentiate between "=" and "==", the only situation in which it would have been useful.

Who would invent such a horrible feature? My best guess is that it started out as a cool idea that was fun to implement. Now it has become a selling point; people frown upon editors that don't support it, even though they would be better off without it. This is a common enough phenomenon; examples include semi-transparent console windows and other eye-candy.

I recommend that you take the red pill: Edit your code without syntax highlighting, or at least settle for a minimalistic approach with just two colours (one for comments and one for code). Be warned that your code may actually look rather ugly without its colourful front, but at least you'll be seeing it for what it really is.

The emperor isn't naked this time around. He's wearing an amazing technicolor clown suit.