Syntax Highlighting Off
Former neuroscientist here. Please take this article's pop science proclamations with a grain of salt.
1) "Additionally, we process words much faster than we process colors". Wrong, I'm pretty sure areas V2/V4 received information much faster than the visual word form area, especially given that it may require a saccade to take in a long word. Not sure where this claim comes from.
2) "...we instinctively jump to luminous or high contrast colors with our eyes, interrupting reading a program in a more standard way..." Half-true. There are well-known pop-out effects, but it's unlikely we read programs the way we read prose, so it's not clear it's an interruption at all.
3) "When syntax highlighting is on you also are spending cognitive energy (which is finite) on item-specific processing rather than organizational processing." No evidence offered. I could just as easily make the counter-claim, that syntax highlighting frees up the brain to more organizational processing, since there's less load necessary to figure out item-specific properties. Not necessarily wrong, but needs to be tested.
I think the biggest mistakes in the article (and perhaps what he got from talking with his friend in the cognitive sciences) are equating prose with code, and not accounting for novelty effects. I have no doubt that coloring random words in prose disrupts things, since it's novel and captures attention. But it doesn't automatically follow that people experienced with syntax highlighting experience similar effects.
It would be cool to see more actual research in this area.
I'd freely speculate that 90% of the benefit of syntax highlighting comes from mere lexical highlighting - specifically, making comments, strings and keywords visually distinct from everything else. And even keyword highlighting is very secondary to the first two.
Making comments distinct from normal code is nice because you can easily alternate your focus on one or the other while reading through; and you're not likely to accidentally read commented out code as actual code. You're also not going to forget to close out your comment, for languages with paired comment delimiters.
Making strings highlighted makes it a little bit easier to ensure you're terminated your strings, especially in edge cases around escaping and quoted quotes (for languages that have a choice of quote characters).
Semantic highlighting - distinguishing identifiers based on their definitions - is a seriously niche win most of the time, where you're spending ever increasing amounts of CPU for a marginally actionable hint.
I went the other direction, I programmed for decades without syntax highlighting because back in 1989 I thought ANSI color directory listings were for MS-DOS weenies, so I used a monochrome terminal for everything. I finally became a software developer and adopted syntax highlighting and haven't looked back. Catching unterminated strings and mismatched do..end blocks in ruby saves an incredible amount of time where you can just fix it immediately in-editor as you are coding.
I find it amusing that now we've got hipster programmers wanting to get back to basics and reject syntax highlighting. Trust me, its not better, colors do make you more efficient.
Next step: programming using ed.
But jokes aside, use whatever environment you like best. For me syntax highlighting is extremely useful. Knowing whether some strings of characters is a type or a variable, or a class type or a basic type makes programming just that much easier. It also helps catching simple typos if something doesn't have the color you'd expect.
This post misses, for me, the greatest benefit of programming without syntax highlighting enabled. I went through a period of doing it for 5 years or so and the biggest effect was ultimately on how I wrote code, not how I read it.
Without syntax highlighting I gradually became more focused on the legibility of what I was writing, because none of the visual cues were there when I read stuff back. Function length, module size, naming and vertical whitespace were are all things that I began to think more deeply about.
I turned syntax highlighting back on a few years ago because I was getting so many complaints from co-workers when pairing on stuff at my machine. But I definitely think the experience made me a more considerate, better programmer and I'm glad I did it.
Syntax highlighting can help structuring your source code when done well and tastefully - coloring your source in all bright colors of the rainbow rather achieves the opposite effect.
Personally I am working with a white background, so I try to keep the syntax colors all very dark, so while the different colors can be seen, they should not distract from reading. The correct amount of highlighting very much depends from the language at hand, but it can be very helpful in separating elements, just as an example take this function parameter list:
func foo(name, family string, age, size int) {
The correct reading of this parameter list entirely depends on the placement of the commas and the knowledge that "string" and "int" are parameter types - highlighting the type elements can help a lot.
With the availability of high-dpi displays, perhaps colors should be replaced with more traditional ways of markup as used in book-printing, replace coloring with different typesets and fonts.
I've had syntax highlighting enabled in Vim for many years without really thinking about it. I just recently started to learn a new programming language (Go) and that got me thinking about the effects of syntax highlighting. I felt that colours would distract me from efficiently learning the syntax of the language so I turned it off for a while, now I'm never going back.
(I really do like having another color on just comments though, code > comments. Separating them makes a big difference when reading source code for me.)
Ended up having to create a Vim color scheme to get what I wanted: https://github.com/ggustafsson/Static-Color-Scheme
I've always wanted to try this.
I started programming in 7th grade by randomly typing commands into my TI-83 during algebra class. I had no syntax highlighting, auto-complete, or even a choice of font, but I would sit there for _hours_ meticulously making lines jump around the screen.
Now I get stressed out when my color scheme isn't perfect.
I started programming a long time ago, without any syntax highlighting at all, and the first time I tried it I found that all the different colours were more distracting than without, so count me as another for whom it's always remained off.
On the subject of unusual programming preferences, perhaps antialiasing off would be the next one the author could try. For me completely off is most comfortable, regular grayscale antialiasing is just bearable, and subpixel (like what's shown in his screenshots) just makes me feel dizzy after a short time.
I do something very similar (grey strings/comments, some bold/underline identifiers): http://i.imgur.com/i5j0QKT.png
I don't understand the reasoning behind this. What possible benefit could you get from turning off all syntax highlighting?
It's useful to distinguish between language keywords and user specified names. Being able to visually ignore one of them, while focusing on the other, is a tremendous benefit. It cuts down the number of things you need to hold in your head at once, by half.
It's useful to distinguish between local variables and instance variables. It helps to better understand the dependencies that exist between a method and other methods/state.
It's useful to distinguish between mutable variables, and constants. It tells you at a glance how something is being used, and the pitfalls you need to watch out for.
Turning off all syntax highlighting destroys all of the benefits above, and I can't think of any notable benefit you would get out of it.
I guarantee you, whatever "upside" you think you're feeling right now, it's simply the novelty effect. This is a very common phenomenon in AB testing. Often times, you see an initial improvement, simply because users respond positively to the initial novelty of something being different. I guarantee you, if you continue to work without syntax highlighting for 6 months, and then turn it back on for a few weeks, you'll realize how much you actually love it.
"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."
How about an analogy from cooking, too?
"It's easy to spot all the verbs, but why on Earth would you want to do that? "
Well, exactly! Makes it obvious how stupid your argument is, huh?!
I'm pretty sure the people who choose syntax colouring know what they're doing, just like the ones who don't use it. One of those choice things.
In hindsight, while comments and strings deserve syntax highlighting there's an argument that the rest is a solution looking for a problem. I'd argue that the highlighting would be better-spent giving each nested tier of parens a distinct color. Like make the first tier brown, then do ROY G BIV, and if you need more than 8 tiers I don't want to read your code.
Some people are definitely in the camp against syntax highlighting.
Some examples:
1. Linux Akesson (LFT) wrote an article quite some time ago about it: http://www.linusakesson.net/programming/syntaxhighlighting/
"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."
2. The Acme text editor does not support syntax highlighting and probably never will. Prominent contributors to golang use this editor.
On my own, I started to program without syntax highlighting, then used it and now I use a much weaker one. I like to be able to track individual variables by color as a form of semantic highlighting and to bring up comments rather than dimming them like it's often done.
What I've once read is that the advantages for syntax highlighting are biggest for beginners (in general or in that programming language). This seems logical when looking at what syntax highlighting does: colouring differently according to the token type. Beginners might have more problems finding the borders of what belongs together and what kind of token something is.
If we compare this with classical text, we won't have any typographic help for the inner structures of sentences, maybe simply because colouring different types of words differently was quite hard. Typography there is used for the outer structure. Mostly vertical space is used to separate paragraphs. This is also used in programming. However making headlines bigger and use a different type isn't used in programming. Programming uses indentation instead. It is pretty obvious that it's this way because of the limitations of the medium in the beginning. Also it's not as easy as classifying tokens.
Syntax highlighting is a topic where EVERYONE has an opinion, so I'll give my 2 cents as well. I am using solarized light (http://ethanschoonover.com/solarized) for my coding, and am very happy with it. I like having keywords emphasised, because they convey a lot of the structure of the program. If you need to switch syntax highlighting off to see whether code is ugly or not, you might not have a very refined sense of beauty anyway. That said, I am perfectly fine with programming without syntax highlighting, I am not dependent on it to understand code. It is similar for type inference: I think it is OK if it makes your code easier to read, if you use type inference though to a point where you cannot understand / write your code without it, you are doing it wrong.
I'm on exactly the opposite end of the spectrum (and no one else seems to be supporting the full opposite position, so I may as well). I use use emacs with rainbow-identifiers-mode[1] enabled, which gives every variable a different color. I can't say for certain that it makes me more productive. I just turned enabled it on a lark when I installed spacemacs. But it's fun, and looking at code without it on seems somehow boring now. I'm definitely more comfortable with it on than with it off.
undefined
Nice experiment and I encourage any developer to tune up their tools so they are happy.
My experience is the opposite: I use syntax hilighting on Emacs, TextMate, and the JetBrains IDEs. When I SSH to a server and use Emacs to edit code, I find it jarring if syntax hilighting is not set up for whatever programming language I am editing. I can't read and understand the code as fast.
No thanks.
I started using syntax highlighting still in the MS-DOS days, and hate when I am forced to downgrade my developer experience.
But to each its own I guess.
undefined
I use syntax highlighting, but I prefer it to be quite minimalist. I use bold for keywords and different colors for string literals and comments. Also I use underscore for object fields. Modern IDEs usually configured with a lot of visual noise and it might make it harder to read, but probably it depends on person.
I'd like to see slightly more difficult to read fonts as an isolated experiment in this exploration. http://www.wired.com/2011/01/the-benefit-of-ugly-fonts/
Thanks. I use Jetbrains IDE's for coding where my colorschemes have a similar setup. Code, Comments, Strings, are different, and that's about it. Never got around to doing this in Vim which I still use for many tasks (who doesn't?). So this is much appreciated.
I think the usefulness of syntax highlighting is highly dependent on the amount of colors you use. For me, anything more than three separate colors is just visually distracting.
It's also nice to have low opacity comments, as many others have said.
Oh, and never bright colors. I use solarized or similar.
Purely eye candy here--visual enjoyment that makes code seem more interesting and fun.
Did anybody else go from needing a white background, to preferring a dark one?
(I had the zebra effect for years when trying to read light-on-dark, then one year something changed--I don't know exactly what.)
Many color schemes take the most important parts and fade them out: comments!
In Haskell I have different colors for the comments, keywords, and literals. That's it. Anything more is not helpful.
It's baffling to me to look at source on Github and see a screen full of comments, greyed out.
I have had syntax highlighting off for a few years, but I always turn it on when looking at XML... especially poorly formatted files. It helps my eyes navigate the soup. That's where I think the value is: it helps to make up for confusing formatting.
I've found that I really appreciate my editor's (aoeui) use of blue and black foreground colors for matching up parentheses and other brackets. Keyword highlighting is less useful apart from being a cue for correct spelling.
I can't recall who, either Pike or Crockford said that syntax highlighting was a regression. I kinda agree that a well balanced comment code ratio, and clear system / design makes up for most editor enhancement.
undefined
Many syntax highlight themes seem to hide comments in code by decreasing their contrast. I'm strongly against that so for me the author lost credibility when I saw that's more or less only what his theme do.
There's an Atom theme called Hacking the Kernel that does some minimal bolding of keywords but is otherwise monochrome. I use it at times but never thought about whether I was faster with it.
let's have a version for emacs !
"Reading code is simply more straightforward, smoother and less jumpy. I get the overarching context faster and with less hassle."
This makes me think the author might be one of those people who can not superficially scan text very efficiently and resort to.. well, just reading it, word by word. (Is there a term for this phenomenon?)
