
The impact of syntax colouring on program comprehension [pdf] - joubert
http://ppig.org/sites/default/files/2015-PPIG-26th-Sarkar.pdf
======
pheroden
I've been writing code professionally for 20 years, and as an armatur for 30.
I can parse code much quicker if it has syntax highlighting. If you don't,
that's fine, but it doesn't mean your more experienced or somehow better than
those that do. I always hate conversations about this because it always seems
to come down to a dick measuring contest where everyone seems to think that
more monochromatic the longer it is. It's not. Use what feels right to you.

~~~
Arnt
I can parse code much quicker if doesn't have syntax highlighting... or so I
thought until I tried a properly subtle colour scheme (offwhite with various
_dark_ foreground colours, as it happens). I wonder how many of the colour-
objectors really object to inappropriate colours rather than to their
existence. Pale blue on white, bright green on white, etc.

~~~
SmellyGeekBoy
I'm also in the light background, dark text camp, when it comes to code at
least. I think Visual Studio (using the light rather than dark or blue themes)
has the colours just about spot-on for me, especially in the 2015 editions
where they seem to have softened the palette a bit.

That said, I'm completely the opposite when it comes to the command line. I
think colour coding can add a lot (ls for example) but it has to be light-on-
dark or not at all. Funny how that works.

~~~
kazinator
How that probably works is that with this distinction, you know at a glance
which windows on your desktop are editor windows with code and which are
command lines (or possibly editors that have suspended to the background to go
to a command line).

It's ... meta-syntactic-highlighting for your entire desktop! Different types
of windows are colored differently, just like different kinds of identifiers
in one window.

------
jpollock
I've been programming for 30 years now, I remember back before syntax
highlighting. I had a bug that I couldn't track down - it took forever. I had
an infinite loop that would only run 3 times and then exit.

Here was the problem:

    
    
      for (int i=0;i<3;++i) {
        /* Initialize important things.
        frozzleTheNozzle();
      }
    
      while (1) {
        /* Do ALL THE THINGS. */
        makeSureTheNozzleStaysFrozzled();
      }
    

Syntax highlighting prevents the entire class of bugs from happening (as do
compiler warnings, but hey). I told one of the other guys I was working with,
and he introduced me to emacs which had just gained font-lock mode.

~~~
mikeash
The lack of syntax highlighting in your comment really illustrates the problem
nicely. Took me longer than it should have to spot the problem!

~~~
0942v8653
Heh, I tried to scroll to the right to see the rest of the line. Swift's
nested block comments would sort of fix the problem, but syntax highlighting
would work with C.

I will say though that highlighting comments and strings separately from the
code doesn't necessitate full syntax highlighting. I remember (and have saved
somewhere) an article on syntax highlighting where only comments were
highlighted.

------
Chris_Newton
I wish we had more understanding of how effective different presentation
styles really are when working with code.

For example, personally I much prefer quite mild syntax highlighting —
depending on the language I might distinguish things like comments, literals,
and maybe some routine keywords and punctuation that could be de-emphasized.
I’d also choose colours that didn’t jump out, but were distinctive enough not
to confuse, say, a literal string with an identifier.

I don’t see the attraction of colouring 67 different classes of code fragment
in 67 barely distinct colours myself. On the other hand, many popular editors
and colour schemes do this, so it would be interesting to know whether I’m
missing out on something that might be helpful.

What I do find very useful is the kinds of context-sensitive highlighting that
some editors will do, for example showing matching delimiters and maybe the
region between the innermost ones, or showing all references to and any
visible definition of the identifier under the cursor. Subtle highlighting is
still preferable to in-your-face bold colours, at least for my taste, but I
find these kinds of tools do help me to navigate and understand code more
efficiently.

------
cgag
I've been experimenting with minimal highlighting using a theme I stole from
jcs (mine (haskell, rust):
[http://imgur.com/jNgBHpn](http://imgur.com/jNgBHpn), his (c):
[https://i.imgur.com/PkNOjBZ.png](https://i.imgur.com/PkNOjBZ.png)) and I'm
surprised how much I enjoy it.

edit: forgot to link to original post:
[https://lobste.rs/s/9ruzgw/screenshots_from_lobsters_users_2...](https://lobste.rs/s/9ruzgw/screenshots_from_lobsters_users_2015/comments/e7v1d8#c_e7v1d8)

The dotfiles are linked in that post. It only really looks as pictured if you
copy both the vim theme and the Xresources and use something that respects
.Xresources like urxvt.

~~~
aerique
I prefer my highlighting to not so much highlight specific things but to
partition the code into easily parse-able blocks.

The default --angry fruit salad-- syntax highlighting of most editors and even
other people's themes are usually too much for me. This is what I use:
[https://raw.githubusercontent.com/aerique/emacs-theme-
aeriqu...](https://raw.githubusercontent.com/aerique/emacs-theme-
aerique/master/aerique-dark-theme-1.png)

~~~
cgag
I dig it. Which font is that?

~~~
aerique
Terminus, I've tried out (and still try out) many fonts for programming but I
always come back to this classic.

------
mhd
Never mind the results, but 10 graduate students? That's a rather narrow
margin of experience and small set in general.

~~~
jlouis
n=10 is a small set. In addition, you don't know if there is a prior bias
here. Say most of the 10 grads use syntax colors in their daily work. This is
likely to perturb the numbers.

Figure 2 shows the plain samples have much greater variance, but does that
translate to significance? Some analysis here would be nice, but with n=10 you
don't have enough samples for this to be significant I'd wager.

Also, the test should have thrown in a color scheme which _nobody_ has ever
used as a control. I think the choice of color scheme matters a great deal as
well.

~~~
zokier
> Say most of the 10 grads use syntax colors in their daily work. This is
> likely to perturb the numbers.

Wouln't you say that is representative of the general programmer population?

------
mafribe
Fascinating, but not surprising that the study concludes that the "effect
becomes weaker with an increase in programming experience".

Maybe of interest is Hughes' discussion [1] of the different forms of syntax
colouring. It was discussed on HN before [2].

[1] [http://www.wilfred.me.uk/blog/2014/09/27/the-definitive-
guid...](http://www.wilfred.me.uk/blog/2014/09/27/the-definitive-guide-to-
syntax-highlighting)

[2]
[https://news.ycombinator.com/item?id=8378799](https://news.ycombinator.com/item?id=8378799)

------
LarryMade2
Been programming for over 30 years, I like syntax highlighting, along with
good formatting.

I do say that there's good and bad highlighting, I will tweak the highlighting
colors and appearance if I can, I find many highlighting schemes are more
distracting than useful. And I' sure my preferences may not meld with others.

------
yuumei
Can we now remove the comment in .bashrc for every ubunutu install:

    
    
      # uncomment for a colored prompt, if the terminal has the capability; turned
      # off by default to not distract the user: the focus in a terminal window
      # should be on the output of commands, not on the prompt
      #force_color_prompt=yes

~~~
efaref
This comment annoys me. I want a coloured prompt _so that_ I can focus on the
output of the commands, which become neatly boxed by my coloured prompts.

------
ntoshev
Having monospaced / proportional font test as a sort of control would have
been nice.

I've been wondering what is the analogue of syntax highlighting for natural
languages. Still experimenting with it, but most promising is simple keyword
highlighting. I've written a Chrome extension that does this:

[https://chrome.google.com/webstore/detail/highlit/cooahmcpma...](https://chrome.google.com/webstore/detail/highlit/cooahmcpmajfpnanjkdfiejkffphknnm)

Interestingly, keyword highlighting apparently helps some type of dyslexic
people focus their attention on the text. With the web full of distractions,
I've noticed similar effect myself. Keywords also seem to help skimming, when
you're reading the text with a specific purpose in mind.

~~~
vorg
> what is the analogue of syntax highlighting for natural languages

Nouns begin with a capital letter in German, and used to be in Dutch and
English until a few hundred years ago. Perhaps it was because nouns are
generally spoken with the greatest stress of all words in an English sentence.
Perhaps such capitalization is an analogue of programming syntax highlighting.

~~~
rogeryu
Sometimes long complex English sentences can be very confusing to me,
especially in finding the verb in there. When two or three consecutive words
have different grammatical meaning, and can be used in different grammatical
meanings, it can become very confusing if English is not your mother tongue.
In that case, color coding (or bold / italic / underscore) could help a lot.
But for a word processor to do that, it has to understand grammar...

~~~
ntoshev
I've tried part-of-speech tagging and subjectively it doesn't seem to help
much. POS taggers for English are a solved problem, so it can be done
automatically, but for prototyping I tried marking up some text myself. Indeed
what helped the most were the verbs (vs other parts of speech), but it still
didn't seem to be worth doing.

Also marginally helpful was to delimit noun / verb phrases with 2 spaces
instead of one.

------
lmm
Thinking about it one of the things that bothers me about Haskell is that
there's so little syntax that one can't really colour it. Coupled with the
lack of brackets or any other visually distinct symbols, a piece of code
always looks like an undifferentiated mass.

------
truncate
I personally find my syntax highlighting preferences change with mood and
time. Mostly I find them useful. Sometimes I've found them to be tiring to
look at, at which point I use monochrome[1] theme which is good compromise
between no colors and many colors (i.e. 2/3 colors).

[1] [https://github.com/fxn/vim-monochrome](https://github.com/fxn/vim-
monochrome)

~~~
wsc981
For Xcode (Objective-C) I've recently started using the Salander theme, which
looks kind of similar:

[https://camo.githubusercontent.com/6fb786753708404177aaa0a2f...](https://camo.githubusercontent.com/6fb786753708404177aaa0a2ff1248dd77cb9c46/687474703a2f2f6d69636861656c6d616e676f6c642e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30332f73616c616e646572322e706e67)

------
brainburn
Having colors for different classes of code fragment just helps to reduce the
amount of processing of the code in the brain. Seems to me that this is a win,
at least it is for me.

In daily life I use a very colorful scheme (darcula on steroids) and just
thinking about monochrome makes my head hurt.

------
userbinator
I started learning programming without syntax highlighting (on a monochromatic
display), and actually find it distracting to read multiply-coloured text. In
fact I tend to _close my eyes_ whenever I "mentally execute" code, as then I'm
visualising variable values and output instead of the code itself.

Another article from the opposition, which I partly agree with:
[http://www.linusakesson.net/programming/syntaxhighlighting/](http://www.linusakesson.net/programming/syntaxhighlighting/)

(Linus Akesson is what I'd consider a _highly experienced_ programmer, and the
rest of his site is worth looking at for lots of other interesting stuff.)

~~~
joonoro
Oh god that article, I was waiting for someone to post it. I don't mean to
insult your opinion but I just find it cliche because it is _always_ posted in
any discussion about syntax highlighting and it has some serious issues with
false analogies. Comparing syntax highlighted prose to syntax highlighted
code, equating typing on a keyboard to typing on a piano? Seriously? The
author may or may not be a good programmer but that article stinks of BS.

It's nice to see that the comments section is still going strong, 8 years
later.

~~~
thaumasiotes
> Comparing syntax highlighted prose to syntax highlighted code

This just makes me wish you could get syntax-highlighted prose. It's not
necessary for languages you have a native understanding of, but think how
helpful it would be for foreign languages. :/

~~~
Natanael_L
Imagine how much more dense complex sentences could be if colors were used to
disambiguate meanings, and yet still understandable!

~~~
bjterry
Now I'm imagining a variant of Lojban, but where the colors have semantic
meaning. It could be super dense.

------
soyuka
Reminds me of Damian Conway that finds syntax coloring distracting, always
wondered why.
[https://youtu.be/aHm36-na4-4?t=10m23s](https://youtu.be/aHm36-na4-4?t=10m23s)

~~~
rhaps0dy
In the video, he shows the standard coloring for vim. That coloring is indeed
flashy and more distracting than no coloring at all.

I tried having no syntax highlighting for a few months, and it was usable, but
not as good as with syntax highlighting.

~~~
bootload
_" I tried having no syntax highlighting for a few months, and it was usable,
but not as good as with syntax highlighting."_

A lot of the problems I have with Vim and syntax highlighting is using VT100
or badly configured graphics systems. Personal taste, one style I do use is
the old Borland colours which came out with Turbo Pascal. Works on all the
monitors I've got ~
[http://www.vim.org/scripts/script.php?script_id=92](http://www.vim.org/scripts/script.php?script_id=92)

------
sklogic
I wonder if these results are somehow related to a weird fact that dyslexics
have far less troubles understanding the coloured text (even a transparent
coloured overlay can be sufficient).

------
donatj
I wonder about the potential of syntax highlighting English.

~~~
lucozade
Syntax highlighting works because colour components are preattentive i.e. your
brain picks out hue, saturation, intensity/luminance differences in constant
time. Size, proximity and orientation work too.

That's why some schemes work better than others: what you want to find quickly
is key structural signals in the code. If you highlight comments strongly,
say, it'll miss the point (unless your proof reading comments of course).

So, to your question, the value will depend on whether or not there are
structural cues that it'd help sufficiently to highlight.

Interestingly we do do that to some extent already. For example, indenting and
capitalising the start of sentences, indenting (and spacing) paragraphs,
italics and bolding for emphasis. That sort of thing.

So using highlighting in the places we currently do could well improve what we
already have. For example, colouring the first word in a paragraph or
increasing the font of the sentence capital.

What would be fascinating to study would be if we could use it to help with
word or sentence stress. I could imagine that, done carefully, this could help
with learning languages.

------
now
I don’t understand figure 5. The left and right images are not only of code
that’s not highlighted and that’s highlighted, it’s for two completely
different functions. Of course eye tracking is going to be different.

Even though it’s not really worth noting due to the first issue, the right
example also seems to require more focuses (87 over 65)?

------
psiconaut
Funny that nobody has mentioned unbalanced parenthesis yet... Too much color
can be distracting, but catching paren structure at a glimpse has no price.
Very interesting article, we need more of this 'measure, don't speculate' kind
of science.

------
scotty79
Here's Douglas Crowford on coloring he'd like to see in his code editor:

[https://youtu.be/b0EF0VTs9Dc?t=899](https://youtu.be/b0EF0VTs9Dc?t=899)

------
sitkack
Next hypothesis to test: Does the existence of syntax highlighting enable less
skilled programmers to write overly complex code?

------
thesz
Note that experience has exponential speedup for completion time.

------
mkj
From figure 4 we can draw the conclusion that the most experienced programmers
shouldn't use syntax highlighting?

~~~
saurik
Note that that is a negative log, and so isn't saying the person was slowed
down (which you may or may not have thought, but just verifying).

[https://groups.google.com/d/msg/golang-
nuts/hJHCAaiL0so/kG3B...](https://groups.google.com/d/msg/golang-
nuts/hJHCAaiL0so/kG3BHV6QFfIJ)

~~~
userbinator
Actually they were slowed down:

"Thus, if a participant completed the plain version of a task in 60s, and the
highlighted counterpart in 30s, the time advantage for that task is 60s/30s =
2"

The part of the range below 0 corresponds to time advantages < 1, i.e. it took
_longer_ for the highlighted part than the plain one. Several times longer, if
the results are to be believed (there's one around -0.7 and three at -0.5;
that's a "time advantage" of approximately 0.2 and 0.3, or 5x to 3x slower.)

~~~
saurik
Huh. You win this round. FWIW, I actually get pretty seriously tripped up for
a moment when I am staring at syntax highlighting that is unlike the syntax
highlighting I have become overly used to...

------
tejohnso
Syntax colouring is for children.

[http://www.youtube.com/watch?feature=player_embedded&v=dkZFt...](http://www.youtube.com/watch?feature=player_embedded&v=dkZFtimgAcM#t=15m58s)

Crockford is always right.

~~~
erik14th
He's joking, his proposed "scope highlighting" still has syntax highlighting.

