|   |
A case against syntax highlighting
Do you rely on syntax highlighting
when developing software? If so, you may be shooting yourself in the foot. In
this post, I will argue that syntax highlighting, while aesthetically
seductive, moves focus from content to form, and discourages those who look at
the code from trying to understand it.
An example of syntax highlighting.
Background
Syntax
highlighting is a standard feature of most modern text editors and
development environments. The basic idea is to exaggerate the visual difference
between various syntactical elements, to make it easier for the programmer to
distinguish between keywords, punctuation and variable names.
Why was syntax highlighting invented in the first place? Did the
programmers get the syntax all mixed up when reading code, thinking that ")"
was perhaps a variable name or even a preprocessor directive? Of course not.
While reading computer programs is often difficult, the difficulty comes from
the intricacies of the program, not from the syntax.
Legibility
Perhaps syntax highlighting was invented to speed up the reading process. Yes,
that must have been it, highlighted code must be easier to read. After all, it
has colours!
Well, no. One of the basic rules of thumb in typography is that, when writing a piece of
text, you should choose one typeface and stick to it. Likewise,
a
splash
of
colour
may grab the reader's attention, but it will inevitably decrease the
legibility of the text. The natural flow of the text is broken, and it takes more
brain effort to piece together the individual letters into words and semantics.
Cognitively, the reading process becomes slightly less automatic and slightly
more conscious; leaving less room in the conscious part of the mind for
actually understanding the text.
Semantics are more important than syntax
Understanding is vital when reading code. Unlike novels or newspaper articles,
where you can skim through a paragraph and learn the gist of it, software is
inevitably full of complexities and important details that you just have to
take the time to understand. To do that, you need to be looking at the code
at the semantic level.
Syntax highlighting applied to fiction. It's easy to spot all the verbs, but why on Earth would you want to do that?
And even when the code is already well-known to them, most developers would
rather come across (and fix) memory leaks, security holes and inefficient
algorithms than mere syntax errors. Syntax errors will be found by the compiler
anyway; the developers shouldn't waste time looking for them. But if syntax
highlighting biases their minds towards the syntax of the code rather than its
meaning, wouldn't they end up doing just that?
I'm not saying that developers are stupid. But since we all miss the
occasional bug here and there — everybody makes mistakes — I think
it would be a good idea to configure our tools to help us find them, rather
than help us miss them.
An example of bypassing the learning curve: Training wheels.
Learning curve
Maybe syntax highlighting wasn't intended for experienced programmers. Maybe
it was introduced in order to flatten the learning curve for newbies,
much in the way that some misguided piano teachers put coloured stickers on the
keys. I suppose the piano teachers do it to improve communication ("press the
yellow key now!" rather than "play an F now!"), but do they honestly believe
that children are unable to learn note names? They will have to, eventually,
and then they will have to un-learn the colours.
The same phenomenon can be seen in user interface wizards. An advanced
operation in, say, an image manipulation program is complex, and the complexity
confuses new users. Enter the wizard dialogue box, which will skip or automate
some of the steps, at the cost of flexibility. In the end, users only learn how
to use the wizard, rather than the complex functionality itself, so the extra
flexibility is lost. So you're not flattening the learning curve at all, you're
bypassing it.
If you learn to write software in colour, you will probably find it
difficult (or at least awkward) to look at the same code without colours, or
even with a different colour scheme. Seen in that light, syntax highlighting is
an educational dead end. It's like learning how to ride a bike with training
wheels. You won't be able to ride a normal bike until you un-learn some of the
techniques you've picked up along the way.
The exceptions
There are two cases in which syntax highlighting can actually contribute
something. The first one concerns multi-line comments. If you're jumping around
in a source code file, perhaps as part of an interactive search-and-replace
operation, you might end up in the middle of a large block of commented-out code. You
begin reading it as code, and after a while you run into an end-of-comment
token, and realize that you've been reading a comment all along. In this case,
rendering all comments in a different colour would have prevented the
mistake.
On the other hand, that would be a short-sighted solution. Most people
agree that commenting out code should be seen as a highly temporary debugging
technique, and that the commented-out code must be removed or rewritten sooner or later.
Changing its colour to get it out of sight would be like sweeping it under the
rug.
The second case mainly concerns the C language. Accidentally writing "="
instead of "==" can result in a bug that is particularly hard to find, since
you can sit and stare at it for a long time without actually seeing it. This is
the only case I've found, where you would benefit from being able to focus on
the syntactical level of the code, without paying too much attention to the
semantic context. With syntax highlighting it would be possible to mark "=" and
"==" in different colours. Yay! A good reason for implementing syntax
highlighting! But — and at this point it probably won't surprise you
— every colour scheme I've come across uses the same colour to highlight
both "=" and "==".
Conclusions
Syntax highlighting doesn't improve legibility. It encourages you to skim
through code rather than understand it. It makes you focus on syntax errors
rather than real bugs, and it gets in the way of your learning. Arguably, it
even encourages you to procrastinate the removal of commented-out code
blocks. And current implementations of it fail to differentiate between "=" and
"==", the only situation in which it would have been useful.
Who would invent such a horrible feature? My best guess is that it started
out as a cool idea that was fun to implement. Now it has become a selling
point; people frown upon editors that don't support it, even though they would
be better off without it. This is a common enough phenomenon; examples
include semi-transparent console windows and other eye-candy.
I recommend that you take the red pill: Edit your code
without syntax highlighting, or at least settle for a minimalistic approach
with just two colours (one for comments and one for code). Be warned that your
code may actually look rather ugly without its colourful front, but at least
you'll be seeing it for what it really is.
The emperor isn't naked this time around. He's wearing an amazing
technicolor clown suit.
Posted Sunday 26-Aug-2007 11:44 | Discuss this pageDisclaimer: 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.
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... =) | 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 |
|
|
