Navigation
Home & news
Random page
All pages
Site search:
Databases
Fortune cookies
Haikus
SID themes
Page collections
Blag
Chip music
Chipophone
Games
Hardware projects
Music downloads
Obfuscated programming
Piano music
Sane programming
Scene productions
SID related pages
Software downloads
Video downloads
Featured pages
A Chipful of Love For You
Air on a Rasterline
Autosokoban
Beagleboard VGA
Binary Art
Bitbuf
Brainfuck
Chipophone
Chopin romance
Craft
Elements of Chip Music
Fratres
GCR decoding on the fly
Gravazoid
Hardsync
Kernighan's lever
Klämrisk Hero
Live at LCP 2011
Parallelogram
Phasor
Pipe Logic
Poems for bugs
Rasp64
Raster paper
Reverberations
Safe VSP
Shards of Fancy
Sidreloc
Spindle
Swan
Think Twice III
TTY demystified
We learn the nibbles
VIC Timing Chart
Vim + ^Z
Zeugma
Don't miss

Reliable synchronisation of cog PLLs
Forum
Register
Log in
Latest comments
Syndication
RSS feed
Feedback
  • Swedish content
  • Personal content
  • Offensive content

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.

#include <stdio.h> (...)
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.

Alice was not a bit hurt, and she jumped up on to her feet in a moment (...)
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.

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

Posted Sunday 26-Aug-2007 11:44

Discuss this page

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.

Anonymous
Mon 15-Oct-2007 17:45
Hi,

Just read your article ... and no, I am not fully convinced.
Consider intending the code. Going by your argument, is it not just about presentation rather than semantics of code. If you read the code carefully (and have enough time on hand) you can make sense of even the most ugly-intended code.

But still, like intending is a useful tool in hand, so is highlighting. And just like different styles of intending you have the right to have your own style of syntax coloring (or lack of it).

Cheers,
Arun
triad
Linus Walleij
Wed 17-Oct-2007 21:48
I can't remember a single time I was helped by syntax highlighting, perhaps as you state it is a bit comfortable to color out comments, but that's it.

But hey, if only semantics matter we could also do away with indentation and that actually (IMHO) serves some kind of purpose as a perception aid. I also perceive being cognition-wise assisted by EMACS features that blink the line of opening "{" when typing terminating "}" in the edit buffer.

The visual studio/visual assist/eclipse guys will say auto-completion helps a lot in object-oriented development. I dunno. I once saw it as a way of trying to deal with unnecessary hierarchies introduced by too much OOP.
Anonymous
Thu 25-Oct-2007 09:38
I don't blame you for hating the colors that you've shown here. They're a hideous rainbow of confusion.

Maybe you wouldn't be arguing against syntax highlighting if you'd just try a simpler color scheme. An advanced editor like Visual Studio will actually help you understand what you're looking at...for instance take this random piece of code:

x = Thinger.Convert(y);

Is Thinger a class with a static Convert function? Or is it a property member of the class that this code lives in? With Visual Studio you will know because if it's a class it'll be Aqua colored and if it's a property that returns a class object, it'll just be black (by the default color scheme).

Well, with a name like Linus on a guy from Sweden, I wouldn't be surprised if you are a *nix guy who hasn't used Visual Studio much though.
Anonymous
Thu 25-Oct-2007 09:43
This argument is specious and it is absurd beyond all reckoning. Coloring every word of a paragraph in natural language is in no way similar to syntax coloring in a programming language.

I just cannot believe that anyone could take this argument seriously.
Anonymous
Thu 25-Oct-2007 13:21
I think the idea of syntax highlighting is to clarify the syntax so that the brain can more easily ignore it. Basically, it takes the job of recognizing the structure of the source you're looking it, out of your hands, letting you focus purely on the semantics of the code.

English prose, where the syntax forms an integral part of the reading experience, is completely uncomparable with code, which needs a rigid syntax primarily to help the compiler, not the programmer.
Anonymous
Thu 25-Oct-2007 14:13
Wait a minute, is this linkbait? Syntax highlighting? With compilers, debuggers, code generators, visual editors, and so many other tools that are constantly abused or relied on as a crutch, you complain about syntax highlighting?

And how do you prove your point? By creating a feeble straw man. We don't color our prose just as we don't start our programs with "once upon a time." The only thing in common in those two snippets is that they can be stored as a stream of ASCII characters. They serve complete different purposes and should never be conflated.

While I agree that some editors go overboard, I don't think you should throw the baby with the bathwater. Being able to step back and see the outline of your piece of code before you dive in again is extremely valuable once you grow beyond the hobbyist project.
lft
Linus Åkesson
Thu 25-Oct-2007 15:43
Thank you for all the feedback! Some of your arguments are really good, e.g. the one about indentation. I'll have to think about that.

Many of you complain about my comparison with prose. However, I don't use that as an argument in the text. I even write "Unlike novels..." in the section about semantics. I added the Alice in Wonderland quote as an amusing illustration. Perhaps some of you were just skimming through the article, rather than trying to understand it... =)

I believe that some things should not be made as simple as possible, because when a task is too simple, people do it without thinking. Developing software is complex and error-prone, so people need to be thinking when doing it. And yeah, I realize that these opinions are controversial to some.
Anonymous
Thu 25-Oct-2007 16:54
Having programmed since the middle eighties when there was not syntax coloring. I would call foul, maybe you have a horrible color scheme but color syntax helps you when coding to actually write code that will compile vs. code that won't.

Maybe you only use intellisense for picking types in which case maybe you can get rid of highlighting, but since I type faster than intellisense 90% of the time, I like the color changing to a "type" color when I am done. It also makes finding un-escaped quotes in strings easier.

Want a story where syntax helped? OK. I used to work with the worlds worst speller, he spelled dEfault dAfault which in c/c++ is fine it just becomes a tag named "dafault:" and compiles merrily along. The misspelling is hard to spot reading through code, when at least for myself, I automatically correct misspellings when I read, but with syntax coloring it is VERY obvious. Note: He did not use coloring and I did. He spent days on the bug and had no clue. I spent 10 minutes.

Feel free to not use syntax highlighting, but if you work for me and I find a bug that would never have been had you colored your code, don't be mad when I say I told you so.
Anonymous
Thu 25-Oct-2007 17:21
This is idiotic. If syntax highlighting helps you, use it. If it doesn't, don't. But don't try to make a creaky argument for a personal preference, treating as objective something that is entirely subjective.
Anonymous
Thu 25-Oct-2007 19:40

lft wrote:

I believe that some things should not be made as simple as possible, because when a task is too simple, people do it without thinking. Developing software is complex and error-prone, so people need to be thinking when doing it. And yeah, I realize that these opinions are controversial to some.
Bad behavior -- like smoking, shoplifting, or checking in code without unit tests -- should be made hard. Everything else should be made as simple as possible. Your own article confirms this. You don't dislike syntax highlighting because it makes it too easy for you to code, instead, you dislike it because you find your editor's fruit salad syntax highlighting distracting enough that it makes it _harder_.

I will give you another example I dislike wizards myself, not because they make my life too easy, but because they lead to a false sense of security and frequently mangle my own code. They make my life harder pretending to make it easier.

lft wrote:

Many of you complain about my comparison with prose. However, I don't use that as an argument in the text. I even write "Unlike novels..." in the section about semantics. I added the Alice in Wonderland quote as an amusing illustration. Perhaps some of you were just skimming through the article, rather than trying to understand it... =)
Pictures are supposed to reinforce the ideas in your text. When you take one to argue an opposing view, you are misusing a powerful tool to "trip" your readers. Does it mean that images should be abolished or that they should be used in a more congruent way?
lft
Linus Åkesson
Fri 26-Oct-2007 15:53
Bad behavior -- like smoking, shoplifting, or checking in code without unit tests -- should be made hard. Everything else should be made as simple as possible. Your own article confirms this.

Exactly. And making changes in code that one doesn't fully understand is bad, dangerous behaviour.

You don't dislike syntax highlighting because it makes it too easy for you to code, instead, you dislike it because you find your editor's fruit salad syntax highlighting distracting enough that it makes it _harder_.

But my point is that syntax highlighting makes it easier for us to dive in and fix the code before we understand it, because it encourages us to skim through the code on a superficial level. The syntax highlighting distracts us from seeing the forest by making it easier to see the trees.
Anonymous
Tue 30-Oct-2007 14:52
First, sorry for my bad English.

First, and most important. If you color some program in random colors, like you did with your Alice In Wonderland text, it REALLY will be hard to read.

Computer program is not intended to be read sequentially, instead it contains several layers of semantics, tokens grouped into higher order structures. For example, thanks to syntax highlighting, when you are searching for an identifier, you can skip comments, string constants and operators. In computer program SAME english
word can have different meaning in different places and therefore will confuse you and will slow down your work. Syntax highlighting can show you, for example, that you are using library subroutine name as variable. And, in C, this can be a serious problem. In fact, ability of Visual Assist to distinguish between macros, variables and functions makes this seriously outdated language much more bearable and allows for using more powerful and dangerous features ( especially preprocessor :) ) without fear of shooting youself in the foot.
Anonymous
Thu 13-Dec-2007 12:51
I tend to agree with you on this. The only meaningful use of syntax highlighting is differentiating between the various classes of text you may encounter in a source code: code, strings, comments.
They change the meaning of text profoundly, so it's very handy to have a way of quickly making a distinction between them.
But once I see that "x = func(a) + 2" is code, I can figure the rest on my own, thankyouverymuch.
(And quotes and such are often typeset differently in real books, too.)

[Oh, and I just came here for the Parallax score... :) Eh, happy St. Lucia Dag or whatever you call it :) ]
Anonymous
Fri 14-Dec-2007 16:14
Ehh... Syntax highlighting actually helps me. Anyone know Eclipse? And anyone know Java? If you do, you propably know that Java is very case-sensitive. As I have the habit of typing very fast, i'm not very accurate. If I didn't have syntax highlighting, I could write System.Out.println instead of System.out.println and not notice anything. But because I have the marvellous highlighting of Eclipse, I see it straight away because the "Out" wouldn't be blue and in italics, as it would be in correctly typed code.
Anonymous
Fri 4-Jan-2008 17:00
If you color some program in random colors, like you did with your Alice In Wonderland text, it REALLY will be hard to read.

They're not random at all! He assigned colours to words of certain grammatical function. I don't know if he coloured it in all right, but verbs are one colour, nouns are another, adjectives another.. ect. It's annoying to read because our brain naturally "parses" the sentence.

Code, however, is another story. I'm not a professional programmer, I'm a physicist, but often I use colour to make proofs easier to read. Similarly I find colour coded and properly indented code to be much easier to read. But to each his own.
Anonymous
Wed 16-Jan-2008 21:19
Hi just read this I do actually think I partly agree, and you wrote it in a way that made me enjoy reading it a lot! Thanks for being funny, you lit up my boring evening. :)
carlsson
Anders Carlsson [Zapac]
Tue 22-Jan-2008 12:12
I don't like "Christmas tree" highlighting. That's why I prefer to use Emacs, either through a standard terminal window or with colours turned off. I'm all for automatic indentation and brace matching though.
Anonymous
Mon 28-Jan-2008 13:54

lft wrote:

Thank you for all the feedback! Some of your arguments are really good, e.g. the one about indentation. I'll have to think about that.

Indentation is much more semantics than syntax, that is why indentation
actually adds readabilty to your programs.
Anonymous
Thu 21-Feb-2008 21:46
I fully disagree with your article. There is nothing controversial about ignorance.

You are turning a personal preference into an objective matter, without even discussing the subjectivity of the matter at all. To stack upon, a misleading example of freakshow highlighting (which you connect directly to the article by its subtitle) and a totally irrelevant comparison of learning curves, even though syntax highlighting was introduced to evade common syntax errors and enabling skimming through large source codes more easily. This new feature aimed towards professional developers, since the use of computers was mainly that of developers and academics.

And yes, I know what you'll say here; "Skimming is no good, you miss things and that's bad." Well, let's take your own example of the color splash. We both agree that it takes a longer time to read those words than the main, black text, right? But as we know, professional syntax highlighting almost never colors two words next to each other in different colors, it colors the key words in one and the rest in black. Common exceptions are comments, classes and variables. This means that you read mainly black, non-highlighted code, and occasionally your eyes fixates on a variable or class name.

In this case (general programming), it is a good thing that it takes a bit longer to skim through just that word, because it is important. We don't want to miss the semantic structure, as you wrote. The result of this skimming would be a list of class names instead of classes, to more easily find what we want to focus on. Next, we step into the class and understand the parts of it by the hierarchy we retrieved from our skimming through highlighted code. The same principle is implemented all the way down.

As mentioned above, it is a very good thing to be able to differ classes from properties. Without syntax highlighting, I cannot think of a quick way to determine the object type. It is also easier to identify upper/lowercase errors on-the-fly.
Anonymous
Mon 10-Mar-2008 12:07
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.
First of all, the brain processes colours with one side and understands text with the other, so you're just using both sides of the brain in stead of just one. The only "bad" thing about it is that you use more energy, but that doesn't mean it takes more time to figure out what the code does. On the other side you find the bug a lot faster so overall you save energy.
/*Second, try this piece of C code:
void main(void)
{
int d, d, ad;
printf("%d%d", dd, ad);
}
/*or PHP:*/
$pet_name = 'Pet name';
$info->name = "{$pet->name}: {$pet->name}<br />";
//in stead of
$info->name = "{$pet_name}: {$pet->name}<br />";
/*If you have previously defined both $pet (object) and $pet_name (string), you might not notice that -> is an operator. Maybe you didn't do it, but someone before you did, there's a bug in the program and now you have to find it.
It's probably hard to find where my code starts and where it ends because you don't highlight comments.*/

In the C program, there's a /* without an ending */ before void main(void). The /* may be 50 lines above and your compiler keeps complaining there's no main() function, but you can swear there is because you see it.

-Tom
Anonymous
Sun 6-Apr-2008 16:29
I think you have a case for a lot of languages, but one interesting case is that of LateX - without syntax highlighting you really have to stare at the screen to see if you've written \subsection{} which is an operator, or subsection{}, which the typesetter will parse as normal text. By the way, I know that LateX is not a programming language, but I feel it's relevant.
Anonymous
Sat 3-May-2008 23:20
The syntax-highlighting shot looks like Vim, am I right?

I'm using Vim a lot too because it's a really great editor, but it's syntax-highlighting is indeed really crappy and useless.

On Eclipse for example there are only 2 basic highlighting colors for the stuff Vim does too: green for comments and bold purple for keywords and builtin-stuff. All other colors are used for special things like highlighting enums, classes etc. or placing a grey background behind the parts of the code that won't be parsed because of preprocessor-statements like #if, #else and so on.
Highlighting of strings, numbers, operators etc. like Vim does it isn't done by default, because it's useless most of the time.

I think the highlighting of Vim could be much better if it would only highlight comments and keywords like Eclipse does (If you ignore the things like highlighting defined variables and so on that aren't possible with a simple editor because it doesn't know all source-files of your project). Maybe the Vim-guys tried to use as much colors, as an IDE uses for all things it's able to highlight, to highlight the basic things that are normally highlighted with only 2 colors :P
Ferruccio
Tue 22-Jul-2008 13:51
Thanks. You expressed this notion much better than I did:
http://the-lazy-programmer.com/blog/?p=9
Anonymous
Thu 24-Jul-2008 22:09
I think the highlighting of Vim could be much better if it would only highlight comments and keywords like Eclipse does (If you ignore the things like highlighting defined variables and so on that aren't possible with a simple editor because it doesn't know all source-files of your project). Maybe the Vim-guys tried to use as much colors, as an IDE uses for all things it's able to highlight, to highlight the basic things that are normally highlighted with only 2 colors :P
You can write your own syntax highlight file where you only specify certain items to be highlighted.
papasmurph
Papa Smurph
Sun 24-Aug-2008 18:54
I tend to use syntax highlighting to see syntactic errors in multi-language source. When writing web applications it's typical to deal with HTML, Javascript, PHP and SQL mixed in the same file, so it's beneficial to see where one thing ends and another starts. I agree that semantics is the main "problem" in programming, but as I yet haven't found an editor that understands strings containing SQL it's still a good thing to highlight the string itself with all the escapes etc. It's very easy to get hard to find errors in SQL sequences.

What I do to lessen the fragmented appearance of syntax colored text is to at least always use the same text format: Whenever an editor chooses italic or bold by default for certain items I set that back to normal text. That makes items pop up less, and the text hence becomes easier to read.
Anonymous
Sat 13-Sep-2008 03:17
It surprises me that this topic generates so much heat! It's not as if Linus is threatening to take away your syntax-highlighting, is it?

I do think that syntax-highlighting traditionally tends to put emphasis on the wrong things — boldfacing language keywords and the like — but I do find it useful; I can follow the syntax more easily, which lets me focus my attention on the semantics of the program. I think comic books have shown that doing something similar to syntax highlighting on English text, by boldfacing the words that carry emphasis in the sentences, also improves readability.

You can see some of the kind of syntax-highlighting I favor at http://canonical.org/~kragen/sw/urscheme/ — comments and “noise words” like “if” are faded out a bit, and the names of functions being defined are in a conspicuous blue color which makes it easy to scan for them (rather like boldfacing a header or a term being defined). I could improve on this (it’s just Emacs’s default syntax highlighting) but it's pretty good already. The extras in the vim example in the article don’t add a great deal, to my eye, although they don’t seem quite as distracting to me as to Linus.

— Kragen Javier Sitaker <kragen@canonical.org>
Imperceptus
alexander miglin
Wed 17-Sep-2008 17:23
I honestly think that any development that has stemmed from HTML needs syntax highlighting. I do remember when I didn't have it amidst making websites, I am very thankful that I do now.

Although I would agree that languages like c,c++ or even .net could really do away with them with no loss to the author.
Anonymous
Thu 23-Oct-2008 19:29
Agreed. My highlighting is very reduced (black font in general, green comments, bold keywords, blue strings).
Anonymous
Thu 20-Nov-2008 06:20
My thoughts are some of the arguments are weak, and syntax highlighting is definitely something that's far more personal preference than anything else.

However, I'd add that "syntax" highlighting alone really isn't all that helpful in understanding a piece of code. +Maybe+ for entering code, but not much else.

On the other hand, +semantic+ highlighting would be in many cases, quite useful, but I've yet to see any editor support it.

For instance, how helpful would it be to see, just from color, that a symbol is not just a variable, but it's a globally scoped var, or a local var?

Or that a member of a class was shared, public, private, or whatever.

Personally, I'd find that type of highlighting far more informative.
Copperblade
Angelo Bertolli
Fri 21-Nov-2008 01:49
Syntax highlighting is really a feedback mechanism that lets the programmer quickly know when he's made an error in what he thinks he's telling the parser: it's biggest benefit is in letting you know exactly where your tokens begin and end according to what you've typed. It's more than just aesthetics.
Anonymous
Tue 6-Jan-2009 15:58
"Perhaps syntax highlighting was invented to speed up the reading process."

You thoroughly persuaded me that prose text should not be color-coded. Good job. Only prose text works by a very different mechanism than code. Code is a set of detailed, logical instructions for a computer to follow. Prose is generally either descriptive, persuasive, explanatory, or emotive--none of which applies in the least to computer code.

You say that color coding leads to this: "Cognitively, the reading process becomes slightly less automatic and slightly more conscious." But one paragraph later you say this: "software is inevitably full of complexities and important details that you just have to take the time to understand." So wouldn't you want the code reading process to be less automatic and more conscious, so you can take the time to understand what you're reading?

"Syntax errors will be found by the compiler anyway; the developers shouldn't waste time looking for them." Come on, we all know that syntax highlighting isn't about finding syntax errors. It's about disambiguating between properties and methods, or strings and code blocks. It actually clarifies the semantic content that the syntax might hide.

Here's the crux of my counter-argument, and it builds on your notion that semantics is more important than syntax: The semantics of code is tightly bound to the syntax. Natural language is horribly inefficient (by comparison) because of the redundancy and error-correction built in. With a person, you can say something ungrammatical (i.e. with syntax errors) and still be understood. With a computer, you can't just say, "Aw, you know what I meant to write--stop complaining and just do it."

~ philosaur
lft
Linus Åkesson
Thu 8-Jan-2009 19:43
Code is a set of detailed, logical instructions for a computer to follow. Prose is generally either descriptive, persuasive, explanatory, or emotive--none of which applies in the least to computer code.

I strongly disagree. Yes, computer code is a set of instructions for a computer to follow. But it is also a means of human communication, and a good programmer strives to write code which is indeed both descriptive and explanatory.

You say that color coding leads to this: "Cognitively, the reading process becomes slightly less automatic and slightly more conscious." But one paragraph later you say this: "software is inevitably full of complexities and important details that you just have to take the time to understand." So wouldn't you want the code reading process to be less automatic and more conscious, so you can take the time to understand what you're reading?

This is a good point. I don't mind slowing down the reading process as such, but when all of that extra time is spent doing cognitive work rather than intelligent reasoning at the semantic level, nothing is gained. There's a trade-off between quantity and quality here, and my original article (or rant, if you prefer) fails to identify it.

Here's the crux of my counter-argument, and it builds on your notion that semantics is more important than syntax: The semantics of code is tightly bound to the syntax.

Again, I don't agree because code is also written for human readers. By changing the names of a few identifiers, reorganizing your data structures, changing the order in which some code is executed -- even though it does not affect the runtime behaviour of your program -- you can help or mislead your audience, and even transform the program from solving problems in one domain into solving (seemingly) different problems in another domain. And when you return to the same code three months later, those choices will have a great effect on how you decide to take the program forward. Code is written for people.
Anonymous
Wed 25-Feb-2009 02:47
Oh, you clearly missed the point of syntax highlighting...

Secret: Its use is to easily spot typos (forgetting an " etc)
Anonymous
Tue 14-Apr-2009 12:58
This is bullshit.

A lot of the time you don't "read" code, you scan it. If you're looking for constructor calls or error messages (strings) then yes, only actually *reading* the green text is many times faster and less error-prone.

In normal text you don't skip every verb (or noun or whatever) but when briefly browsing code you *can* skip strings (green) and just look at the blue words (if,then,else,while,...) plus indentation to get the general flow of the function.
Anonymous
Tue 28-Apr-2009 01:09
Det blev en skillnad, så jag kan inte annat än att hålla med dig. Det blev ju mycket läsvänligare.
GingerBread
Fri 29-May-2009 07:47
Computer languages are not about computers, but about humans thinking about programming them.
So, if you argue that colors make you lazy. Why not get rid of the language as well?

I never really used assembler, until I found the AVR. And, yes, I learned so much about The King doing that.

Let no light distract us from our path towards that elevated brightness. Thanks for sharing your 'Craft',
it enlightens my way.
Anonymous
Sat 30-May-2009 01:19
It's easy to sometimes forget a closing delimiter on a comment, leading to a bug hunt and wasting your time. This is one utilitarian reason for using syntax highlighting.
Anonymous
Sat 6-Jun-2009 22:23
I don't blame you for hating the colors that you've shown here. They're a hideous rainbow of confusion.

Maybe you wouldn't be arguing against syntax highlighting if you'd just try a simpler color scheme. An advanced editor like Visual Studio will actually help you understand what you're looking at...for instance take this random piece of code:

x = Thinger.Convert(y);

Is Thinger a class with a static Convert function? Or is it a property member of the class that this code lives in? With Visual Studio you will know because if it's a class it'll be Aqua colored and if it's a property that returns a class object, it'll just be black (by the default color scheme).

Well, with a name like Linus on a guy from Sweden, I wouldn't be surprised if you are a *nix guy who hasn't used Visual Studio much though.

Uahh, sorry but as a serious programmer you *should* not rely on syntax highlighting to distinguish between a static function and a property. You always have to know what you are using or calling otherwise you're doomed to produce errors sooner or later. Also any serious programming language should avoid such misunderstandings as much as possible thus making highlighting mostly obsolete.

For identation I think it is a complete other story. I think identation serves more the purpose of paragraphs, making longer texts better readable as long as identation do not reach ridiculous levels.
Anonymous
Mon 13-Jul-2009 23:26
Thanks for making me more aware of this. I completely agree with lft, I also agree with the others but I think some are missing his point. Basically I see it as this:

When syntax highlighting is distracting, turn it off.
When syntax highlighting is useful, turn it on.
Anonymous
Fri 7-Aug-2009 22:33
Here's something I find handy about syntax highlighting - brackets, in javascript and many other languages its really useful when nesting code.
Anonymous
Sat 29-Aug-2009 23:58
/*Second, try this piece of C code:
void main(void)
{
int d, d, ad;
printf("%d%d", dd, ad);
}

You have another bug, which syntax highlighting is useless for: you double-define 'd', and you use an undefined variable 'dd'. ;)
Anonymous
Sun 30-Aug-2009 00:02
I think you have a case for a lot of languages, but one interesting case is that of LateX - without syntax highlighting you really have to stare at the screen to see if you've written \subsection{} which is an operator, or subsection{}, which the typesetter will parse as normal text. By the way, I know that LateX is not a programming language, but I feel it's relevant.

Actually, it is. TeX, the language underneath LaTeX, is fully Turing complete, and a BASIC interpreter for it exists. Google if you don't believe me.
Anonymous
Sun 30-Aug-2009 00:11
"Syntax errors will be found by the compiler anyway; the developers shouldn't waste time looking for them." Come on, we all know that syntax highlighting isn't about finding syntax errors. It's about disambiguating between properties and methods, or strings and code blocks. It actually clarifies the semantic content that the syntax might hide.

Properties vs. methods? Syntax. Strings? Syntax. Code blocks? Syntax. Yeah, I'd pretty much have to say that syntax highlighting has *nothing* whatsoever to do with code semantics, and *everything* to do with discovering syntax errors, and quickly.

Syntax highlighting, in all honesty, WAS introduced with the express intent of helping the coder review his code before kicking off a compile. Anyone who has worked in anything beyond a hobby project knows that a compile run can take minutes to complete, even with partial compilation. Who wants to wait that long?

Syntax highlighting is utterly invaluable from a static analysis point of view.

Here's the crux of my counter-argument, and it builds on your notion that semantics is more important than syntax

I only wish that were true. My favorite languages are Forth and Lisp. Yet, nobody codes in these awesome environments. Why? The stack is too hard for people to grok, or, there's too many parentheses.

Let's just all admit it together now: syntax matters, and it matters BIG-TIME.
Anonymous
Sat 5-Sep-2009 11:42
Fascinating... it appears that the most popular argument for syntax highlighting is in fact "spell check". Except it isn't usually set up so that my variables, a rather small dictionary by most measures, are properly spell-checked, even in languages where they are declared.

Block folding though (note that a comment block is also a kind of block)... now that's the stuff!

Now a little mind-experiment diversion: screen reader, "audio syntax highlighting".
Anonymous
Fri 11-Sep-2009 15:53
Glad to see you are hardcore pro syntax highlighting, reading the "The exceptions" part of your, it easy to see that you are against bad highlighing schemes, but then again who isnt?
Anonymous
Tue 27-Oct-2009 20:29
OMG!!! :DDDDD
Anonymous
Sat 14-Nov-2009 16:41
Although I'm not sure if highlighting keywords/constants actually improves your efficiency of coding/debugging, I'm sure that syntax highlighting does help searching. For a significant amount of time during coding, our eyes are searching stuff. Where's that class/method/function/variable? By highlighting them, we can quickly locate the things we're looking for, which reduces a lot of frustration. You don't necessarily have to use colors for highlighting (though it's the easiest to implement). You could use bigger fonts, for example. This is what people (including you) are actually doing when they put headlines into an article. It just makes easy to navigate within the document. Of course, you can use a search function in your editor, but searching strings can be quite disorientating because you have to jump around the code and you'll certainly lost the sense of contexts. But it was an interesting article anyway. Thanks.

Yusuke Shinyama
Anonymous
Wed 9-Dec-2009 05:23
To those who claim syntax highlighting is good/necessary/expedient in spite of the rationale in the original post, examine this:

http://www-cs-faculty.stanford.edu/~knuth/screen.jpeg

When your code is of quality >= Knuth's, go ahead and claim victory for syntax highlighting. Until then I too am doing without it...
Anonymous
Thu 18-Mar-2010 20:51
Syntax highlighting applied to fiction. It's easy to spot all the verbs, but why on Earth would you want to do that?

When you are learning about verbs. Duh.
Anonymous
Tue 23-Mar-2010 13:51
Didn't read through the comments, but I think your article is totally wrong.

Especially since C/C++ is not a normal language with lots of redundancies, it is crucial for reading C/C++ that you decipher the syntax as quick as possible to be able to continously reading the semantic.

Following your line of argument, you should remove all whitespaces and all line-breaks, all colours and everything from the source code before reading it. As it's all "only syntax". Non-sense!

The syntax highlighting helps to keep track of the semantic, it does not draw attention away from it!

Good syntax highlighting is used to mark different semantic contextes a word can appear in. Italic for static globals, blue for reserved identifiers, cyan for macros etc. It is uttermost important to reading the semantic that you know about the semantic context. In normal language, this is done by placing words on certain positions or by capitalize them (e.g. in german, all nouns are capitalized). It evolved because it makes text much easier to read.
Anonymous
Sun 2-May-2010 17:40
No, why in the world should we have syntax highlighting?
Do you color an 'F' differently from '6'? Just imagine how this would look:
38D2F4672B1AA9

You ARE writing code in machine code, right lft?
Using an assembler or compiler would be waaay to 'easy'.
Like driving a bicycle with training wheels.
lft
Linus Åkesson
Mon 3-May-2010 06:17
Using an assembler or compiler would be waaay to 'easy'.
Like driving a bicycle with training wheels.

A high-level programming language adds power by allowing you to express complex ideas concisely. Training wheels remove power by replacing a hard job with a superficially similar but easier job. It's like taking an acting class in order to become an engineer.
Anonymous
Sat 8-May-2010 23:46
I agree that people should consider "taking the red pill", but for a different reason. I don't believe that syntax highlighting affects the understanding of code in any way (i.e. not better, and not worse).

However, I do believe that people tend to become too dependent on their specific environment. Today people are completely dependent on having bash, colorls, vim/emacs with all their own specific plugins and configuration files, etc.

Give someone who, supposedly, feels at home with Unix a system with no more than a traditional /bin/sh, the simplest form of ls and nothing more than vi, and they moan like they've been ordered, by their mom, to clean their room before they can go out and play.

I don't mind having all the bell's'whistles, but I also use the most basic of tools (ed, ftw!) from time to time, because I don't want to have to waste an hour setting up "my" environment if I need to do something with a system which is new to me.

I'm impressed with some of the vim hacks I've seen. But I'm honestly even more impressed by people who can function at full capacity without them.
Anonymous
Fri 23-Jul-2010 00:18
i agree with most of the pre-commentators. syntax highlighting basicly adds another dimension to visuallizing the hierarchy of the code, like indentation does. i am a novice programmer, but i never found myself thinking about the syntax highlighting, unlike stated in the article. i merely notice when it isnt there, unlike automatic indentation. i see the main purpose for writing code, not for reading it. when i miss a quotation mark or misstype a language keyword, the mistakes are easy to spot.

additionally, colors make your code look much more friendly :)
Anonymous
Fri 23-Jul-2010 16:23
I think it's more on the part of the programmer rather than the program you're editing your code in. As a programmer, I make my code readable because it's the right thing to do. Highlighting has never been a hindrance to me, because I never relied on it. I learned about highlighting long after I started programming. I don't use a debugger, I still actually add lines to show me what's been done... Call me old-school, or weird. But good code helps others, as well as you, know what you meant to do. Just like commenting your code.

But I also like Syntax Highlighting. It's something that actually helps me program. I got into my Highlighting area, and added words I know I'll use. Everything that has to do with strings is one color, math functions another. It makes it easy for me to see where things are happening in the program. Yet it's not a crutch or a training wheel, because I don't rely on it. Without it, I can still chart the flow of my program.

I see your point about not starting with it. However, I don't see a reason to get rid of it. I learned to program in BASIC. While BASIC can do things, that doesn't mean that I should have never graduated to C or further because those things help me do things faster. A good analogy would be this. You start in BASIC. Now, you move on to either C or Fortran. Well, some people prefer C and some prefer Fortran. OK, so program in the one you want to. And if you replace C with "Syntax Highlighting", and Fortran with "Syntax Non-Highlighting" there you go. Use what feels right.
Anonymous
Sat 24-Jul-2010 11:56
(I didn't read the too many comments before posting)
I do rely on syntax highlighting, and I think that nearly all your points are wrong.

You say the difficulty comes from the semantic of the program, not its syntax. No, it comes from both. I have tried a lot of languages, and never encountered one whose syntax had zero problems, so any help is welcome (besides, knowing several languages means being confused more easily by small syntax differences, unless my editor helps with colors).

You argue that color draw attention too much and that it becomes cognitively harder to read because of the mental overhead of processing colors.
That is very true if you use bright primary colors like in your Alice example, but a good (sober) color scheme actually do not distract, only give more information to the reader. Another thing: prose is very different from code, since its syntax is not at all relevant in the same way. Today, most default color schemes for code are not very colorful.

Concerning the mental overhead, you'll find that text color is actually processed at a nearly-hardware level by the brain. Once you are accustomed to read colored valid code, colors will only stand out when the code is invalid. The rest of the time, when the code is syntaxically valid, I can fully concentrate on the semantics. I'd rather discover (and correct) any syntax error sooner than later: running a compiler is *way* slower than having your editor tell you. And this kind of time waste is one of the very worst in software engineering.

You mention the "only" use you found for colors: knowing if you are in a comment. This can be extended easily to knowing whether you are in a valid string, or whether you made a mistake in the quoting inside the string. So that instantly makes two use cases (ok that was easy).

You say that colors make it more difficult to find bugs. Could it be that you have never encoutered a bug that was caused by syntax alone ? Compilers don't catch everything, and sometimes you use interpreters, which choke on syntax at runtime.

Your whole comparison to training wheels implicitly assumes that the end goal is knowing how to read/write code without colors. But since it is more difficult without colors, it is also less desirable to do so. My end goal is coding better and faster, so I choose to be helped by tools like a good editor and syntax highlighting. If I'm less good at writing code when there is no color, it does not matter at all, since I choosed not do otherwise.

So, I'm not convinced at all. I know by experience that with colors I can read/write better code more easily and faster. Can it really not be the case for you?
Anonymous
Mon 26-Jul-2010 01:49
Word, man, word!

The first thing I do when stumbling over syntax highlighting in vi, is to do a simple ":syntax off".

Thanks a lot for a very nice website!

//magnus
Anonymous
Mon 16-Aug-2010 17:03
Hello lft,

Syntax highlighting is simply enhancing perceptible information. It redundantly presents essential information (i.e. the code). Syntax highlight does not *add* information, it enhances it.

It's one of the basic principles of design, and since you're into typography I kinda expected you to be familiar with this.

I always smile at hardcore coders with black&white screens, who think basic principles of cognitive psychology don't apply to them :)
Anonymous
Tue 17-Aug-2010 08:42
Hi Linus,
I also disagree with you. OTOH, I want to point out that there *are* sensible and stupid syntax highlighters and color schemes. The example that you provided is indeed a bad one: I don't need strings, numbers, and operators to be colored differently.
What I *do* need is indeed coloring of comments and high-level identifiers, i.e. function/class/method names.
That really enhances the perception when skimming through code.
Have a nice day,
Hans
PS: I am sorry, I have not read most of the anonymous comments yet, so maybe this has been pointed out earlier.
lft
Linus Åkesson
Tue 24-Aug-2010 18:06
Hello lft,

Syntax highlighting is simply enhancing perceptible information. It redundantly presents essential information (i.e. the code). Syntax highlight does not *add* information, it enhances it.

Do you also consider the prose example to be enhanced? My point is that enhancing and distracting are two sides of the same coin.

It's one of the basic principles of design, and since you're into typography I kinda expected you to be familiar with this.

On the contrary, a basic rule of thumb of typography is to stick to a single font. SOME people use CAPS to indicate EMPHASIS, thus BREAKING this rule. I find that it makes the text less readable.

I always smile at hardcore coders with black&white screens, who think basic principles of cognitive psychology don't apply to them :)

I'm happy to have made you smile.
Anonymous
Thu 26-Aug-2010 16:13

lft wrote:

Hello lft,

Syntax highlighting is simply enhancing perceptible information. It redundantly presents essential information (i.e. the code). Syntax highlight does not *add* information, it enhances it.

Do you also consider the prose example to be enhanced? My point is that enhancing and distracting are two sides of the same coin.

The prose is not enhanced because the colors don't enhance essential information. In your example, you emphasize verbs and nouns. These are an important property of linguistics, but it is not essential to recognize these words as nouns, verbs or adjectives to comprehend the story. I have no idea what "type" of words you used in all the sentences of your article, but I understood it perfectly well anyway.

To put it another way: it's not essential to know if the word "was" is a noun or a verb in the sentence "Alice was not a bit hurt", whether it is highlighted or not. But it *is* essential to know that "char" indicates a data type, whether it is highlighted or not.

lft wrote:

It's one of the basic principles of design, and since you're into typography I kinda expected you to be familiar with this.

On the contrary, a basic rule of thumb of typography is to stick to a single font. SOME people use CAPS to indicate EMPHASIS, thus BREAKING this rule. I find that it makes the text less readable.

I think you might have misunderstood my point. Contrast most definitely is one of the basic principles of design. It is brought to code in the form of syntax highlighting through colors, and brought to written language in the form of a change in size, weight, style, spacing or orientation of the typeface.

You use it on your site too: headings and subheading are written with a larger and bolder font, quoted text is encapsulated in a container that separates it from the normal text, links are underlined and have a different color than the normal text.

Your "PEOPLE WHO USE CAPS"-example is simply an example of improper use of emphasis, not a case *against* emphasis. It's like putting green text on a purple background and saying "see, syntax highlighting is evil because this particular example is unreadable!"

lft wrote:

I always smile at hardcore coders with black&white screens, who think basic principles of cognitive psychology don't apply to them :)

I'm happy to have made you smile.

This was not meant to come across as a sneer at you. I enjoyed reading the article, the comments and your reply. I think it's an interesting discussion and I'm simply trying to understand your point of view. To be honest, your rebuttals are not really convincing and often contradictory.
lft
Linus Åkesson
Sun 29-Aug-2010 19:45

lft wrote:

Do you also consider the prose example to be enhanced? My point is that enhancing and distracting are two sides of the same coin.

The prose is not enhanced because the colors don't enhance essential information. In your example, you emphasize verbs and nouns. These are an important property of linguistics, but it is not essential to recognize these words as nouns, verbs or adjectives to comprehend the story. I have no idea what "type" of words you used in all the sentences of your article, but I understood it perfectly well anyway.

To put it another way: it's not essential to know if the word "was" is a noun or a verb in the sentence "Alice was not a bit hurt", whether it is highlighted or not. But it *is* essential to know that "char" indicates a data type, whether it is highlighted or not.

Oh, but it is quite essential to know what the word "was" means in order to comprehend the sentence. Part of this knowledge is the fact that the word is a verb -- although it's not essential to know that "verb" is the common terminology for this property.

Likewise, it is essential to know that "char" (or, perhaps more to the point, "person" in a piece of software where it has been declared as such) is a type. Without this knowledge, comprehension and ability to modify the code without introducing bugs would be all but impossible.

But this academic grouping has no business being at the front of the mind during programming; the programmer should be as familiar with the fundamental meaning of the word "char" as he is with the word "was". The fact that "was" and "running" have the same colour is uninteresting when reading a text, since they mean different things, and in a similar vein "char" and "person" are two different types, and it makes more sense to think of them as two separate entities in their own right, than as two instances of "type".

...

You use it on your site too: headings and subheading are written with a larger and bolder font, quoted text is encapsulated in a container that separates it from the normal text, links are underlined and have a different color than the normal text.

Your "PEOPLE WHO USE CAPS"-example is simply an example of improper use of emphasis, not a case *against* emphasis. It's like putting green text on a purple background and saying "see, syntax highlighting is evil because this particular example is unreadable!"

Good point. I see the problems with my example. Nevertheless, I maintain that while some typographic highlighting makes sense (such as indentation and extra whitespace, where it clarifies the intention of the code), automatic highlighting based on syntax is distracting because it emphasizes the shallow syntactic level of the code, rather than the deep semantic level.

This was not meant to come across as a sneer at you.

I apologize for jumping to that conclusion.
Exolon
Oisín
Wed 1-Sep-2010 17:44

lft wrote:

Using an assembler or compiler would be waaay to 'easy'.
Like driving a bicycle with training wheels.

A high-level programming language adds power by allowing you to express complex ideas concisely. Training wheels remove power by replacing a hard job with a superficially similar but easier job. It's like taking an acting class in order to become an engineer.
I don't get your argument against training wheels (or coloured stickers on piano keys for beginners).

You suggest that it's worse than useless because learners have to "unlearn" things after they graduate to training-wheels-free mode.

But that's not a problem if this unlearning process is quicker than the time saved in learning to ride the bicycle, and I would suggest that it is. When you add some kind of training wheels to a task, it's always a trade-off. The brain is extremely good at adapting and if you can break up one complex learning task into many small ones which are easier to master, humans can and do reassemble those small tasks into the larger performance without undue difficulty.

This is why when learning tough piano pieces, dance moves or martial arts forms, we practice them in small isolated segments before putting the segments together. For example, when learning a piano piece you might practice two bars at a time, hands separately, then together, and then one line at a time and so on. Breaking down the tasks, mastering the individual stages and then composing them back together is often much more efficient than brute-force learning the higher-level skill in a monolithic fashion.

We can use mnemonics and stickers and training wheels to help us build those skills on a more modular scale, and we can still master the high-level skill afterwards.
We can have our cake and eat it too.
Anonymous
Wed 1-Sep-2010 19:39
As a not-too-far-offtrack comment: Do Bibles with "The Words of Jesus in Red" add or subtract?

Another thought, having read all the comments (and the article ;): Does the (computer) language being syntax highlighted matter? I find it more helpful for C/C++ and Tex/LaTex, almost useless for eLisp/Lisp/Scheme and Basic.
lft
Linus Åkesson
Fri 8-Oct-2010 07:05

Exolon wrote:

I don't get your argument against training wheels (or coloured stickers on piano keys for beginners).

You suggest that it's worse than useless because learners have to "unlearn" things after they graduate to training-wheels-free mode.

But that's not a problem if this unlearning process is quicker than the time saved in learning to ride the bicycle, and I would suggest that it is. When you add some kind of training wheels to a task, it's always a trade-off. The brain is extremely good at adapting and if you can break up one complex learning task into many small ones which are easier to master, humans can and do reassemble those small tasks into the larger performance without undue difficulty.

This is why when learning tough piano pieces, dance moves or martial arts forms, we practice them in small isolated segments before putting the segments together. For example, when learning a piano piece you might practice two bars at a time, hands separately, then together, and then one line at a time and so on. Breaking down the tasks, mastering the individual stages and then composing them back together is often much more efficient than brute-force learning the higher-level skill in a monolithic fashion.

We can use mnemonics and stickers and training wheels to help us build those skills on a more modular scale, and we can still master the high-level skill afterwards.
We can have our cake and eat it too.

I agree completely in the general sense. To learn a complex thing, we must break it down into smaller parts, as the brain is able to reassemble the parts later.

In the case of training wheels, I would argue that the smaller problem (riding a bike with training wheels) is not a part of the larger problem (riding a bike without training wheels), because the child is trained to compensate for imbalance by leaning in the wrong direction.

The risk with stickers on piano keys is that the student picks up an undesired chain of associations. The goal is to be fluent in this mapping: Sheet music -> Idea of what it sounds like -> Knowing how that plays out on the keyboard -> Motor skills. A common, but unfortunate, situation is this: Sheet music -> Knowing how that plays out on the keyboard -> Motor skills -> Idea of what it sounds like. It's very hard to break free from one of these association chains once it has been formed. Colour stickers tend to form a link between (colour annotated) sheet music and knowing how it plays out on the keyboard, so they will aid in forming the wrong association chain.
lft
Linus Åkesson
Fri 8-Oct-2010 07:22
As a not-too-far-offtrack comment: Do Bibles with "The Words of Jesus in Red" add or subtract?

Another thought, having read all the comments (and the article ;): Does the (computer) language being syntax highlighted matter? I find it more helpful for C/C++ and Tex/LaTex, almost useless for eLisp/Lisp/Scheme and Basic.

My opinion is that having one person's lines printed in a different colour would distract the reader from everything else in the book. However, it is not equivalent to syntax highlighting, because it doesn't emphasize information that is already there syntactically. It would be a case of semantic highlighting, and in most cases a completely useless one, although there might be cases where it clarifies who is speaking. The same effect is used by Terry Pratchett in the Discworld novels, where Death speaks in small capital letters.

I don't mind highlighting per se, when used to mark search results or in the output of grep. In the case of ls, it communicates new information (although aesthetically I prefer the suffix style of ls -F).

Regarding different languages, I would say it depends on whether there are any semantics. Markup languages are sometimes used as a tool to describe structure, without any intricate semantics to understand, and in those cases syntax highlighting wouldn't hurt as much. But if the markup language is used to markup proper text, then the semantics of that text needs all the attention it can get.

TeX poses another interesting problem, which is ligatures. Are you aware that the parser treats certain pairs of letters differently than their constituents? "ff", "fl", "--" and several others. From the point of view of the parser, these are clearly a specific kind of syntactic element. Should they be marked in a different colour? Also, in TeX it is possible to change the lexical kind of any character. You can instruct the lexer to treat the letter y as a backslash, and do this for just a part of the file. Such a change can be effected from inside a macro. A proper syntax highlighter would have to keep track of this.
Anonymous
Fri 5-Nov-2010 20:53
I may agree with you that most syntax highlighters choose to highlight features that are somewhat uninteresting to the coder, rather than more important elements like '=' vs '==' in c. I would love to see nested parentheses and their contents highlighted in shades that depended on the nesting level, for example.

However, I do disagree strongly on the more general sentiment that syntax highlighting is in itself damaging to comprehension in the long run.

You can train your brain to do a great many things, but to not use the inherent skills of the brain is a waste of "talent" and time. If you can leverage peoples' highly developed visual senses to make the semantics more clear, this, it seems to me, is a rational choice, not a crutch. Again, we can talk about whether common syntax highlighters highlight useful things or not, but the notion that syntax can be aided by visual formatting, including color, is something I believe in.

You can do this via indenting, as everybody does, and/or color choice, as syntax highlighters try to do. I would even go further off the syntax-highlighting deep end and propose using larger fonts for higher-level structural elements like class declarations. As John Carmack said in a recent tweet: "Syntax highlighted code is better than raw text, but still not as good as, say, a typical Wikipedia page. Room for structural formatting."
Anonymous
Wed 8-Dec-2010 17:36
A thought-provoking article and interesting read! There is something I'd love to have expanded: why am I "better off without" syntax highlighting if I'm already accustomed to it? I do use syntax highlighting (coding mainly C) and I do agree with you that most of it is a waste of time if you're already comfortable with the language. Having read the article and thinking about it for a minute, it would seem I "use" syntax highlighting for quickly telling apart comments from code, code from macros and allowing me to stay away from accidentally using a reserved keyword (which, as you say, the compiler will probably take care of anyway). But, will I start writing better code if I remove these very simple guides? I doubt it.

I suppose it's like coffee to the regular user: Your own belief in it keeps you coming back for more, even if it doesn't really do much at all.
Anonymous
Fri 17-Dec-2010 11:42
It's nice watching people discuss this king of subject :)
Over the time, people usually change their acceptance about all things.
Its a natural behaviour of human being.
But, as example, who could image that a player without many feature could make so much sucess just due this "beautiful" interface?
People aim for "nice" looking view of thingsbp
Most of people around the world, aim for things that really don't add anything.
Just fill try to fill the gaps in their own concience(and lack of creativity).
At least, most of us here try to create really nice things.
Hernandi - Br - ff.bpt.c
Anonymous
Mon 20-Dec-2010 02:11
Personally, I disagree with this article. Personally I enjoy using Game Maker a lot, and the syntax-highlighting within the program helps me program better. Any language can benefit from it, really; I mainly enjoy it for the fact that you can immediately tell if you might be accidentally naming a variable with the same name as a function or something. Plus it helps me pick out particular sections of code by coloring function names so I can immediately tell where a function is on a long line of code.
Anonymous
Fri 24-Dec-2010 06:18
As if capitalizing the first letter of every sentence wasn't syntax highlighting ...
Anonymous
Sun 2-Jan-2011 18:31
I find this silly.

Syntax coloring makes code more read-able.
You need to be able to read code before you can even understand the content, and programming languages don't usually read like natural languages, but very differently - your failed attempt at reduction ad absurdum using the exmaple of a fictional, natural language text shows that you don't understand this.
You should observe it in yourself, if you are aware enough of such things, that your brain kind of switches operational modes from reading comments in your source files, and then understanding actual code, from one second to another.
Lots of same-colored text forces you to read source code like natural languages, which makes it quite tiresome - at least compared to how I read source code and probably many others, which works much quicker than text reading, maybe your brain works differently.

Also, through different coloring, I need to type less spaces ^^
Which is probably bad should a color blind person ever read my source code, but then he could engange some auto format features of which there are plenty in many IDEs.

Your using of a pretty weird / bad coloring scheme (I'm not referring to the number of colors used, I guess I use no less) here gives an impression of dishonesty, but maybe that was just exaggeration for fun.

With horror I remember the days of monochrome IDEs in MSDOS. Yuck.
Anonymous
Wed 6-Apr-2011 20:11
In the prose example, White should be green like all the other adjectives. Just saying - being the proofreader I am. http://jcoud.com :)
Anonymous
Sat 4-Jun-2011 23:13
Interesting article, on a subject I've also given some thought myself. Haven't read all of the comments, so forgive me if it was already said, but latest advances in semantic highlighting are a valuable aid, especially when dealing with dynamic languages. I've used a semantic highlighter that could catch typos that resulted in undeclared globals that would result in runtime errors later on.

OTOH, one striking memory I have is the first time I came across syntax highlighting: it was when I first saw C code, in Borland's Turbo C environment for MS-DOS. After years programming in BASIC, dBase and Clipper without any special features from editors, my reaction was: "man, the syntax in C is so weird that they need to paint the code!"
lft
Linus Åkesson
Fri 1-Jul-2011 12:16
In the prose example, White should be green like all the other adjectives. Just saying - being the proofreader I am. http://jcoud.com :)

Wow, good catch! While this was a mistake on my part, it's rather striking that it went by undetected for almost four years. Clearly, if the point of syntax highlighting is to make errors stand out, didn't we just witness a rather spectacular failure?
Anonymous
Wed 13-Jul-2011 15:09
I haven't read all the comments, but I read a good few.

Firstly, as for your last comment, your syntax highlighting was presumably done manually. Any failure to catch errors if because they were not caught at the time of the highlighting, not because the sentence is syntactically wrong.

Secondly, your argument mostly makes sense, but I think your premises are wrong.
I tend to skim my code to find my place, and I assume every coder does this. It would be monumentally wasteful to read through even a twenty line block just to find that string that you want to change, or the type of the variable you're using, or to give public access to a member, or whatever.
Basic error spotting aside, syntax highlighting functions less for me like your "highlighted fiction", and more like your bolded and/or enlarged headings which assist me in referencing specific parts of the argument without having to retrace the whole thing.
There may be other ways to achieve this goal (eg using headers and spacing, like in prose)

Furthermore, I find that without it, I can more easily go into "autopilot" and skim -- it draws my attention to what's actually happening, on some level, instead of just reading the words. And the defaults in the IDEs I've used are generally toned down enough (even when they're quite bold) that they're not distracting. In code (which is layed out and parsed very differently to prose) I can quite easily read the words while ignoring the colours (except, perhaps, on a semi sub-conscious level where they direct me semantically as well).

That said, the basic argument that form should be subservient to function, I agree. And I always suggest that new programmers do without any sort of IDE or feature-rich text-editting, because I agree that it's important not to need that crutch when starting out.
Anonymous
Wed 3-Aug-2011 15:14
Greetz lft!

I agree with you in that syntax highlighting generally slowing down code interpreting, since besides the textual information, the coder's brain have to interpret color information too.
But this is the general case.
As you written in your article, comment blocks are an exceptions, but another exception is string blocks. It is much more easy to find an unterminated string if strings are highlighted.
If colours marks blocks, then you don't have to necessarily interpret textual data, like direct code interpretation, so it is making reading quicker. The slowing down problem only appears when you have to interpret both textual and colour information.

So i think the ideal solution is somewhere between your theory and the eyecandy highlighting:
blocks with different function (code, comment, string) have different colour. I think even different code blocks should have other colors in mixed languaged sources (HTML/JS, C/ASM, PHP/SQL), because if you can narrow down the possible locations of the error, then your brain can orientate more easily, between code blocks, because the visible colour borders and you can concentrate immediately on the block wich holds the problem.

Syntax highlight are not bad in all cases, it is about the way of highlighting, that determines it will accelerate or decelerate reading.

Did not read the posts before me, do not know if someone said this before me.

Like your stuffs! Cheerz! (And sorry for bad english.)
Anonymous
Tue 23-Aug-2011 23:25
I don't see highlighting as a tool to catch errors when I'm writing code, I've been programming for so many years that syntax errors are not a common problem. When they do occur, I usually understand the problem from the compiler output.

On the other hand I use both highlighting and visible tabs as a way to help me visualize the structure of the code - code as plain text looks “flat” to me.

Whenever I'm reading code, I'm not reading it sequentially from beginning to end; I might be starting on the overall structure, then narrowing in on the interesting part.
I do not like being distracted by non-code so I like comments and strings in different colors that don't stand out. Instead of pulling the attention to the highlighted code you might say that I'm pulling the attention away from uninteresting parts of the code.

If you asked me which colors I use, I wouldn't be able to answer you; I can't remember. I think I use at least three different colorschemes on a regular basis, depending on whether I'm browsing the code in an editor, a repository browser and so on.
Common for them all is that they're non-obtrusive, keeping the black normal text as the part that stands out the most. (Yes, I prefer black text on a light background.)
Anonymous
Fri 9-Sep-2011 01:03
cd
vim .vimrc
syntax on ---> syntax off
<esc> ZZ
edit a C file

It feels much better now.
I never thought about this before, I just used syntax
highlighting without thinking about its negative aspects.
The code is much readable now. I am able to concentrate more
on its content and not on how it looks.
Great article.

Adam.
wladimir
Wladimir
Sat 8-Oct-2011 19:34
Interesting read! I agree with your article in that focusing on syntax is exactly not what you want. The syntax is the least interesting part of the program, so highlighting based on syntax could be counter-productive. It only shows the most superficial information, which is dead easy to parse with your brain.

However it might be more useful to have "semantic highlighting" instead of "syntax highlighting" for understanding. After all, a program is not plain text either. It is a tree data structure, or a computational flow diagram, depending on the level of interpretation. Some ideas for more advanced code visualization:

- style based on variable name; helps distinguish similarly-looking variable names. Maintenance programmers probably agree this could be useful
- style based on variable scope; this exists in some editors. Is a variable scoped to the object, the function or global?
- style based on depth of parse tree; useful for parsing expressions with a lot of parantheses / unclear operator precedence
- style based on inferred type information
- highlight branch paths (with arrows?), unreachable code
- highlight based on test coverage information

Etc...
Ideally an editor would support multiple views according to what the developer is doing (reading code, searching, reviewing correctness).
fusionfile
August Karlstrom
Tue 20-Dec-2011 22:46
Interesting article and I agree wholeheartedly. My preference is to use different colors only for comments and strings (which are typically the only symbols which can contain whitespace). I also use a variable width sans serif typeface and tabs for indentation. The overall goal is to keep things simple. My observation is that the more "smart" tools we use, the more complicated code we tend to write and this is certainly not a good thing.
Anonymous
Sun 22-Jan-2012 17:39
I utterly disagree! Without syntax highlighting, (or more specifically semantics highlighting) in an IDE like eclipse, I am completely useless as a programmer. I absolutely rely on semantics highlighting to avoid simple, stupid errors like variables being out of scope, or misspelling a class name. "Huh, why is this function call not in blue? Oh, I spelled it mian instead of main!" This has saved me a TON of debugging time over the years, as I never have to compile to understand and fix a sytax error, a template error, a misspelling, or a type error, as the semantics highlighting instantly tells me when something's wrong.

This has also allowed me to understand other people's code better. I instantly know what's a macro, what's a typedef, and what's a struct or class. It's allowed me to parse people's differing naming schemes and formatting rules much easier as well.

In my opinion, syntax highlighting and especially semantics highlighting vastly improve productivity. I would prefer it if we got rid of name formatting conventions altogether and just replace them with colors -- easier to parse, easier to understand, and easier to debug!
Anonymous
Thu 9-Feb-2012 23:48
OTOH, one striking memory I have is the first time I came across syntax highlighting: it was when I first saw C code, in Borland's Turbo C environment for MS-DOS.

Ok, I'm being a total pedant here but it must have Turbo C++. The TC v2.01 I used didn't have highlighting. It had a few bugs though - the most awful of which was implementing fread as a looped fgetc. Two orders of magnitude performance loss (actually about 75x). (TDebug was great). I still have trouble getting myself to use fread() or, thanks to DOS, allocating memory above 64KB.

Back to the point a bit - I think some editors have spent far too much programming effort on their highlighting lexers which could have been spent on useful stuff like ctag support and code outlining.
Anonymous
Sun 4-Mar-2012 19:10
I like to think that there are two types of technology: that which extends human abilities and that which replaces them. Extending human abilities is (usually) a good thing. Replacing them, however, is like getting someone else to do things for you because you don't know how to do them rather than learning them yourself. It is basically giving up potential intelligence.

My favorite example is when web browsers try to remember your passwords for you. You are perfectly capable of remembering your own passwords. Then what happens when you switch computers or something happens to your computer? You don't know your password.

The only possible exception to that that I can think of is if you had a very long password and you were trying to be EXTREMELY time efficient. But that seems to be stretching it.

And I definitely think humans are capable of reading and understanding code that does not have syntax coloring. The syntax coloring only replaces the intelligence of dissecting the code that you could have.

That said, I use syntax coloring. I use it mainly because I am to lazy to do the extra effort of detaching myself from it. I don't think lazy is a good thing, but people are lazy nonetheless, and I wouldn't blame anyone who uses syntax coloring. Aside from that, syntax coloring is pretty (to me, anyway) despite being inefficient, and it makes coding the slightest bit more fun.
Anonymous
Sat 17-Mar-2012 17:53
Is Thinger a class with a static Convert function? Or is it a property member of the class that this code lives in? With Visual Studio you will know because if it's a class it'll be Aqua colored and if it's a property that returns a class object, it'll just be black (by the default color scheme).

I second this argument. Probably the author of the post got his facts wrong. Incidentally, the author has took some pains to point out the real reason behind syntax highlighting, but conveniently labelled them as exceptions. The real reason behind syntax highlighting is to make the structure of the code clear, so that one can understand it better. If the author is using it for eye-candy, it makes one suspicious if they have written any real code at all.
Anonymous
Sat 17-Mar-2012 17:54
Code isn't "text". And this blog post has differently sized bold headings, and different colored underlined links. Seems even plain text is helped with a form of syntax highlighting.
Anonymous
Sat 17-Mar-2012 18:55
Thanks to the guy who linked to this at HN, I feel dumber for having read it.
Anonymous
Sat 17-Mar-2012 21:34
You present your argument against syntax highlighting using 3 key vectors of attack.

1) An analogy to prose text and typography. Arguing what applies to typography, should apply to code as well.
2) An analogy to learning music instruments. Arguing that since you have to to able to read notes anyway, the colors are only temporary. And if they ever change, you're having trouble reading the code.
3) Arguing that syntax highlighting does not help, not even to avoid syntax errors, since that's what compilers are here for.

Rebuttal:
1a) Typography is not a rule like "never do B". It is a contextual form of graphical composition, in which the context determines the set of rules you are going to operate on. For instance, long runs of text with few (if any) structural elements that would attract attention is typically written to be scanned front to back. Mostly that's prose (books, novels etc.). Other forms of writing use different rules, and these may include elements to attract attention to increase typographic legibility (for instance writing for the web http://www.useit.com/alertbox/9710a.html).
1b) It is only of limited merit to compare prose writing with source-code and derive meaning from that comparison. The way we read prose and the way we read sourcecode is vastly different. Typographic rules derived from reading prose do not automatically apply to sourcecode.

2) The analogy to learning music instruments and notes is flawed. You're in essence comparing programming to knowing the alphabet. It just does have no relevance whatsoever.

3a) Based on previous flawed conclusion that it doesn't help, you seek to find some merit by comparing it to error checking by a compiler. The descend into that branch of reasoning is flawed because you have not established validity of your first conclusion, and therefore it is arguing that it doesn't help because it doesn't help, i.e. circular reasoning.
3b) Assuming that any merit can be found in error checking for syntax highlighting is mostly flawed (not entirely however).

Counter:
A: You rarely sit down and read sourcecode front to back. Usually you jump around and glance at many things without reading them again, and again and again. In fact, you recognize visual patterns crossing many lines. Syntax highlighting makes those patterns more distinguishable.
B: Changing syntax highlight might be a bit annoying, but it's usually not a problem (that might be very personal)
C: You yourself admit that there is good reason to syntax highlight multiline comments, stating that it helps to avoid trying to parse text that has no bearing. Likewise, some languages support multiline strings, which accidentially would be trick you into parsing them as sourcecode.
D: Single line comments are easier to spot when highlighted as well, preventing you to read them unless you really want to.
E: keywords and other symbols that you cannot redefine in your program (of which there may be many, depending on the language) are helped to be recognized and avoided if they get painted "offensively".
F: most languages have native types. It is usually relevant to be able to glance at sourcecode and recognize weather it operates mostly with native types, or uses its own types.
G: It is generally useful to instantly see where the system code starts and whatever else is supplied by the programmer.

Resolution:
It's possible (although unlikely) that all raised arguments are valid for you (I can't entirely see how that would be the case however). I'm more inclined to think that it's just easier for *you* to read non highlighted code. Maybe you're a very textual person.
I can say with absolute certainty that I'm not a very textual person. I find non highlighted code extremely tedious to read. I've spent at some parts in my life extensive periods of time in such situations, and they where very painful. Aparts from the benefits that I do derive from syntax highlighting, I do other things to my text environment however that others find abominable (like putting it transparently over a pleasing background).

Conclusion:
Speak for yourself, syntax highlighting is good for me, maybe not for you, but good for me.
Anonymous
Sun 18-Mar-2012 02:26
Be a typography geek all you want, but trying to quickly navigate code is nothing like reading a block of text, so you can't use numbers and studies based on reading English (or any other language) to make judgments about reading code. Syntax highlighting coupled with the indentation used for code it makes it really easy to skim over code and recognize what's going on instead of it looking like a big wall of text. Yes, skimming is important and it's a normal thing to do when you're just looking for a single section where you expect the bug is going to be.

If you don't like syntax highlighting, then don't use it, but don't try to rationalize it with a bunch of information that doesn't apply, and arguments that include saying that skimming code is bad, when in many situations it is the proper way to work. You shouldn't have to read and "understand" and entire class to just modify it or fix a bug in it, sure it's preferred but it's a little bit overkill and honestly, a waste of developer hours.
Anonymous
Mon 26-Mar-2012 05:47
I don't blame you for hating the colors that you've shown here. They're a hideous rainbow of confusion.

Maybe you wouldn't be arguing against syntax highlighting if you'd just try a simpler color scheme. An advanced editor like Visual Studio will actually help you understand what you're looking at...for instance take this random piece of code:

x = Thinger.Convert(y);

Is Thinger a class with a static Convert function? Or is it a property member of the class that this code lives in? With Visual Studio you will know because if it's a class it'll be Aqua colored and if it's a property that returns a class object, it'll just be black (by the default color scheme).

Well, with a name like Linus on a guy from Sweden, I wouldn't be surprised if you are a *nix guy who hasn't used Visual Studio much though.

I use VS at work all the time, but you're actually missing the point here with this particular case.

This confusion can and should be solved by a combination of good naming conventions (I must admit I seriously question the choice of conventions MS used for C#.) and ensuring that you qualify everything except local variables (with "this" for instance members and a class name for static members). Frankly, I don't know why languages allow you to access members without qualifying them. It only leads to problems (like shadowing).

So the case you're describing does not demonstrate the useful of syntax highlighting. Rather, it demonstrates that syntax highlighting is a work around for dealing with a bad practice/language feature. What you've shown is that syntax highlighting makes it easier for us to deal with bad code and thereby encourages it, which is part of the point here.
Anonymous
Tue 10-Apr-2012 21:18
Syntax highlighting is indeed unnecessary, but I think it's helpful. I know that illustration of highlighted English text was meant to be amusing, but it'd suffice to say that the main reason color is distracting in that case is because of annoying colors and untrained eyes. To complement this, if you read Wikipedia often, I doubt you'll be very distracted by inline links or superscript.

However, when I read the C example up top, I plowed through the whole thing in a few seconds. Not much different without syntax highlighting, except for the additional guidance, at whatever value.

I also would stand by refactoring tools and intellisense. If you're writing good code, you definitely do not need them. However, I don't think productivity tools hurt but rather save time when used properly. I can see a possibility for people to accidentally begin relying on these things, but for me it just never happened; I can still code fast without any syntax highlighting or productivity tools. Sometimes it's easier that way.
Anonymous
Tue 15-May-2012 19:03
so a couple of months ago i came across this article, and it helped me realize i was too preoccupied with using the right font and syntax colour scheme in order to understand code better, and even with all that effort, i was still struggling. in a final bid to 'get better' at coding i began to indent and format my code heavily, and comment practically every block of code.

now however, i see things much better, i find it much easier to understand code and went from only being able to write small javascript applications while keeping a reference handy, to working on much bigger and complex projects and even assembler.

so great article in my case :-)
Anonymous
Tue 29-May-2012 17:48
I really think this is a pure opinion debate. You know, like "do you prefer girls with or without makeup ?". Some guys prefer girls with makeup, some others without. It's simple as that ;)

If you want by the way my profound opinion, I'm pro syntax highlighting. But for me it's not at all a "beginner" or "easy learning" stuff, but all the opposite. It's in the range of advanced "productivity tools". I explain a bit : as said by several earlier comments, programming isn't an easy thing. It's necessary to invest time and efforts to master this skill. And such a complex thing must not be learned with the tricks that makes it easier first.

A good approach to basic programming is to use no heavy dedicated studio, but rather have only your compiler and a basic text editor. This way of learning kinda force you to make some very basic errors (syntax) and correct them manually, and force you to understand the workflow of coding -> compiling -> linking -> executing (or whatever, depending on your fav language). I truly think that the best knowledge comes through error : if you make errors, you're able to correct them. And more than that, it creates a massive memory impact, enabling you to prevent further errors better.

So, after working in such a crude manner for some time, you will just be delighted when upgrading to something more user friendly. And you'll discover that some features will simply leverage on your root comprehension to achieve quick and effective result. To stick on syntax highlighting, I simply think it's a cool navigation system to rapidly browse the code, but that's far from the most powerful feature IDEs have to offer. All this hides a real problem, by the way, because it's very common to meet programmers who totally rely on their favorite IDE and are unable to do something outside the vendor's defined scope. That's the true danger : give much power to people that don't understand it...

And to come back on the "training wheels", I would say that you must not learn cycling with them and then re-learn without. But rather you must learn first without training wheels, and when mastered, THEN use them. And you'll be able to do real cool things with your bike that nobody have ever done ! But there I feel the comparison is maybe not so good ;)

As a conclusion, I'd just say that I found the Alice in Wonderland example very cool, but not so much convincing. The syntax of a spoken language is so far from a computer language, and the subset of keywords in the later is so thin, compared to any subset of words in a spoken language (verbs, nouns, or whatever you choose)... So to me it actually makes sense to highlight keywords in code, but absolutely not verbs in Alice. But highlighting dialogs seems to be a cool option. Yeah, I know... semantics ;)
Anonymous
Tue 5-Jun-2012 05:02
In "C", highlighting the braces {} can help when you are looking at someone elses code. Depending on what I'm doing, it would be nice to have some buttons on the editor to quickly enable/disable highlighting various things. I sure wouldn't want everything thing possible turned on and have a rainbow of colors...because it would makes things far worse!!!
Anonymous
Tue 5-Jun-2012 14:07
Syntax highlighting is eye candy, that's why I like it.

Every so often I end up in an environment without it, reading the same old languages that I always do. I am no longer surprised at how monochrome code is just as easy to read as colourful code.

It is however less colourful, which is why whenever I find that VIM syntax highighting is broken, I fix it as quick as possible.
Anonymous
Wed 13-Jun-2012 23:54
Wow, this is a long-lived thread.

I'm not sure who invented it, but the first paper on colour syntax highlighting I can find is here:

Van Laar, D. (1989). Evaluating a Colour Coding Programming Support
Tool. People and Computers V. A. Sutcliffe and L. Macaulay. Cambridge,
Cambridge University Press.

http://books.google.co.uk/books?hl=en&lr=&id=BTxOtt4X920C&oi=fnd&pg=PA217&dq=Evaluating+a+Colour+Coding+Programming+Support++Tool&ots=ODnn6tq2Tj&sig=JSnePqXWhUNDQPzzpNWlB91p_s8#v=onepage&q=Evaluating%20a%20Colour%20Coding%20Programming%20Support%20%20Tool&f=false

The paper showed that when colour coded syntax was applied it led to faster completion of tasks which involved visually scanning code.
Anonymous
Wed 8-Aug-2012 01:02
I find syntax highlight usually disturb me, especially when i am tired. Yesterday, i removed all colors except comment. I want to konw how other people do, then I found your article.

Good writing! Thank you!

--Wang Lei
Anonymous
Wed 17-Oct-2012 12:48
If only more coders would care more about their code. Sometimes simplifying your environment is all you need. Just to quote Brian Kernighan "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."

People would be just as annoyed if this was a post about debuggers versus print statements.

I've come across your article because I was pondering on the same ideas and I just did a google search. Nice article.
Anonymous
Sat 20-Oct-2012 22:37
being a dyslexic syntax highlighting is one of the best tings that have happened to me, if anything i need way more
Anonymous
Sat 2-Feb-2013 20:20
youknowspacesaredistractingwemightaswellremovethemfromourproselanguageaswellwhybotherwiththembeingabletoparsetheindividualwordsisn'tasimportantasunderstandingthesentancesandparagraphsasawhole
Anonymous
Mon 11-Feb-2013 01:03
I have an idea. Text editors should not highlight anything but comments and _incorrect_ syntax. This way we are distracted towards the error, to fix it, else we focus in the code at the semantic level.

What do you think about that?

Cheers,
Sam.
Anonymous
Sat 6-Apr-2013 20:39
Well, that was a lot of talking. After reading everyone's opinions, I've came out with my own. I utilized other thoughts, and here is the result:
If you would apply your logic to everything (syntax highlighting is like training wheels for the bicycle: when you get rid of them, you will get pulled out of the 'comfort zone' and would be forced to relearn again a.k.a use more time in a long run) you will end up living like a caveman. Why? Because electricity is basically the same thing: without it, some people wouldn't live that long and therefore it should not be used at all. For me, it is not the way to go. We, humans, do such things like automation and all that by understanding it must not be applied to EVERYTHING. At least because in some cases it would use up more time. But the main reason, which applies to almost everything invented, that explains why (insert any invention here) is invented at all, is time. This would be the only thing we can't manipulate with / would be able to manipulate in ∞ years. As the saying goes, time is money. And sometimes, you can make more money by using less time. It's like gambling.

In conclusion, use syntax highlighting for your own risk, by understanding the fact, there will be a day when it suddenly disappears...
HoltomS
Stephen Holtom
Fri 17-May-2013 11:40
In addition to the points mentioned above, I'd like to point out that some skimming is *good*.

For example, say a string literal is being passed in a function call. In essence, there are two bits of information for a programmer to be aware of:

1. A string literal is being passed
2. The contents of the string

Now, it is *right* that those things can be considered separately. It's right that I can saccade past the contents of the string if right now I'm not interested in that argument, and need to examine another argument to the function more closely.

It is wrong to be forced every time to track my eyes across carefully, and find the closing quote, before I can look at the next argument to the function. These little inefficiencies add up.

The analogy with a novel is false. A novel must be read in a linear fashion. For most modern code paradigms it's not even clear what linear would mean (a source file, a stack trace, an inheritance hierarchy?). Furthermore the English language does not have the same kind of formal syntactic structures as code: function calls, literals, operators, macros etc are not merely different kinds of words.
HoltomS
Stephen Holtom
Mon 27-May-2013 05:11
It also occurs to me that you've had a bit of a free pass with the "seeing the woods for the trees" comment. It's the kind of statement that seems intuitively right, and most programmers at first glance would consider it to be important.
But on reflection, I don't believe it is important, or even correct.

For any sufficiently complex program, abstraction is incredibly important.

When I'm writing a class I should be concerned with just what that particular class does. And in terms of calling other classes, it should be safe to forget how they internally work. If I can't do this then this implies poor design and a creaky system. And needless to say, there should not be global variables, or shared states. I should be able to focus on a single method at a time because everything is so neatly encapsulated.
So being able to work at the "trees" level is actually an ideal.

Now I'm sure you'll say that what you mean is the big picture: an awareness of what the whole shebang is doing, and is for.
But again, for sufficiently complex programs that level is far above the level of actually looking at source code. Understanding the big picture, and your preferences for displaying code, are very far removed.
Anonymous
Wed 10-Jul-2013 17:20
The language Esperanto is easy for beginners to understand partly because of its "syntax highlighting": all nouns, verbs, adjectives and adverbs have their respective word-endings that make them consistent. One can read a text and pick out all the nouns by form alone.

So no, it's not crazy for natural languages to do this.
Anonymous
Wed 7-Aug-2013 22:17
damn books, people had such better memories before them. My say: it's always better to have an option than not to have one
Anonymous
Sun 25-Aug-2013 23:00
Well, I don't use syntax highlighting anyways.
Anonymous
Wed 2-Oct-2013 12:16
Interesting point of view.

I would generally say that syntax highlighting is not evil :)

I agree that some schemes don't actually work or make the programming eye lazy or cluttered!

The broken learning curve example with the wheel I believe is a loose generalisation.

Actually colored-syntax (there is another case of post formatted code {bold, italic,...}) is
a fast way of getting a top-view of your code's symmetry and beauty... after all programming is
also an art in constant progression :)

As for the the security holes and logical errors or bug-solving, in my personal and humble, if you may, opinion is that syntax highlighting has no actual impact.

Software quality is at most cases achieved by constant redesign and code review.

Yet, I agree with you totally that syntax highlighting should be investigated further because
it could actually play even a greater role in program creation if addressed correctly...

... and maybe ... using syntax-highlighting IS a part of the programmers learning curve (which never ends) to the path of no-syntax-highlighting at all.

Congrats for the article and thanks for your constructive critisism :0
Anonymous
Sat 16-Nov-2013 20:57
stuypidest shit I've ever read
Anonymous
Fri 22-Nov-2013 19:01
cool - an articel written in 2007 still actively receives comments - congrats! :-)
Anonymous
Sun 1-Dec-2013 18:25
Two comments - firstly I have seen English written coloured, in a class with dyslexics the words would often be written coloured and referred to as "green words" and "blue words". That was many years ago now (I'm nearly 40) and I reckon the people concerned still think of the words by colour instead of their actual function in English.

Secondly - a very real use for syntax highlighting - being a dope and forgetting to close quotes in strings. It can be easy to do and hard to see if your code is "contrived example\" (the \ should be \n) but with coloured code, the fact that a lot of stuff that shouldn't be a string IS would be an instant giveaway.
As for your "=" vs "==" problem, any useful compiler ought to throw a warning if it spots a "=" where a "==" is expected, like in if statements. Likewise you ought to get a warning (like "comparison with no effect") if you use "==" when an assignment would have been expected. After all, this==that; doesn't result in anything sensible, logically it will either be true or false. What is that expressed in code? Your compiler ought to tell you about this.
Anonymous
Tue 14-Jan-2014 22:25
If I was highlighting music with colours, perhaps I would consider colouring repeat signs, tempo and phrasing markings, accents and section breaks. Colouring each note differently would be like colouring an int differently than a string. We don't do that in most code highlighting schemes. In the past in my music studies I would colour sections of music with the same theme in the same colour in order to aid memory, while that is different than the highlighting of code, there is indeed a valid use for highlighting in music. Also sometimes I will highlight the tonic of a scale to show it is special for my student's learning.
Anonymous
Mon 27-Jan-2014 13:36
Wow, I can't believe a programmer actually wrote this article.

Anyway, both syntax highlighting and indentation are what's called *secondary notation* in programming. Research has shown many times that well chosen secondary notation helps with program comprehension. In some cases (like indentation) the benefits are huge.
Anonymous
Thu 30-Jan-2014 12:02
Exactly my thoughts since the day I stumbled upon the first editor with syntax highlighting -- the first thing I did was turn it off, and I do it ever since. When I see a screen of code with a distracting mix of awful colors, I can't understand a single line of it.

And I agree on the exceptions too, mostly. My own IDE has exactly two cases for syntax highlighting: Comments and strings.

Apart from that, too bad that "Swedish law applies" to my comment. I may not even touch women in that case ;-)