
Syntax Highlighting Off - clishem
https://www.robertmelton.com/2016/02/24/syntax-highlighting-off/
======
KingMob
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.

~~~
cLeEOGPw
Excellent points. What I would add is that he talks about finite cognitive
energy, but nowhere in the article mentions how highlighting _helps_ to save
the very same cognitive energy.

For example, if there's a comment in the code, without highlight you would
need to follow the comment and look for closing quotes. If the comment
contains escaped quotes it becomes even more difficult. With highlight you
immediately see where it ends.

Another example are keywords - when they are highlighted, you don't even need
to read it. You glance at them and know the meaning by their shape. While
without highlighting you would have to read every single one of them to
understand that they are in fact keywords and not something else.

------
barrkel
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.

~~~
pmoriarty
One of the most important benefits of syntax highlighting that no one in this
thread seems to be discussing is the highlighting of syntax errors. That is
the number one benefit of syntax highlighting for me. It immediately shows me
where there's a problem in my code (like if I haven't closed parenthesis or
quotes) and keeps me focused on "completing the thought", as it were.

This is also a reason that I don't like using editor features that
automatically close parenthesis or quotes when you type the opening pair. That
may make the expression syntactically correct, but semantically incomplete and
the burden will be on me to notice, since syntax highlighting won't help me
then.

~~~
barrkel
Highlighting of errors is, for me, something distinct; a background parse /
compile process that reports line numbers is sufficient. It doesn't need deep
integration with the editor. A keyboard shortcut to go to the next error and
you're pretty much all set.

I'm also not a big fan of overly eager syntax checking because I tend to
compose abstractions on the fly, leaving a statement incomplete while I flesh
out a dependency, or vice versa. Syntax aware indenting usually breaks badly
in this situation - I generally prefer dumb indenting, with an opt-in block or
file format option for where I want to fix code over a large area. I've had
big fights with Emacs over this; it almost always does the wrong thing by
default, whether it's indent location, continuation indent, mixing tabs and
spaces in the indent, etc. About half my .emacs is replacement indentation
functionality and configuration per mode.

I also don't like auto-completing parentheses, because it puts text ahead of
the cursor on the current line. That's a PITA because the editor almost
invariably doesn't know when I want to complete the expression or how. Eclipse
is the worst at this (it's actually not possible to turn off in a sane way).
It interprets RET as completing the expression when I want a line break inside
the parens, and I'm constantly having to go back and forth to work around its
mistakes.

~~~
bpchaps
Autocompleting is by far my biggest pet peeve in modern IDEs. With default
settings in Jupyter, for example, typing """ immediately creates another """.
Another great one is when autocomplete tries to be vindictively clever and
often deletes your open parentheses if you delete its closed parenthesis.
Complete concentration killer.

------
lamontcg
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.

~~~
noir_lord
I tried it with and without recently, I found that for languages I'm familiar
with having it on or off made no difference however having flag errors on off
did.

For languages I don't use much I found having it on more helpful, could I work
without it of course, I grew up with computers that didn't have syntax
highlighting but I'd miss it.

One side result of the experiment was that I turned down the number of colours
I used, not everything needs to be a different colour.

~~~
mst
The only synhi I've ever not actively hated was the elvis defaults on a
slackware install ten years ago, which basically bolded/italiced/faded text
but didn't change the colour.

------
adrianN
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.

~~~
SixSigma
A high number of Unix programmers (Ken Thompson, Brian Kernighan, Doug
McIlroy, Tom Duff & Bjarne Stroustrup) used sam at Bell Labs, which is known
as "ed on steroids, lots of steroids".

[http://sam.cat-v.org/](http://sam.cat-v.org/)

~~~
mavelikara
From an interview with Peter Salus [1]:

    
    
      By the way, 'em' stands for 'editor for mortals' - I 
      christened it that after Ken Thompson visited our lab at 
      QMC while I was developing it and said something like: 
      "yeah, I've seen editors like that, but I don't feel a need 
      for them, I don't want to see the state of the file when 
      I'm editing".
    

[1]:
[http://web.archive.org/web/20080103071208/http://www.dcs.qmu...](http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/)

------
philbo
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.

~~~
scottLobster
I'm glad you had a positive experience, but I'd like to point out that
thinking about legibility, whitespace, naming etc should be done regardless of
highlighting.

I don't blame you, IMO it's one of the major issues with computer science
education. Even basic principles of clean code are often neglected or never
taught, in large part due to the lack of professional experience in academic
circles. This leaves aspiring developers to figure it out on their own, as you
did through turning off highlighting. I'm glad you did, but there are better
ways to learn the same concepts IMO.

~~~
crdoconnor
>Even basic principles of clean code are often neglected or never taught, in
large part due to the lack of professional experience in academic circles.

There's a lack of experience in professional circles too.

One of the questions I always ask during programming interviews (on either
side) is "is your code clean? if so, why?". Invariably the answer is a variant
along the lines of "if it passes the linter it's clean", which is stupid.

I'd like to say that's an automatic fail or automatic "don't work at this
company" but it's just far too common.

~~~
dave2000
Perhaps you should use a less ambiguous term than "clean". They're giving you
a correct answer, so perhaps you should ask the correct question? "Is your
code readable", perhaps? "Are you proud of your code?". Something like that.
No-one's going to admit their code isn't clean, regardless of how they
interpret that term.

~~~
crdoconnor
>They're giving you a correct answer

Is spaghetti code clean if it lints successfully?

~~~
dave2000
Yes. And no. Depends on the context. Microsoft and malware coders both think
windows is great for the same reason; it's very popular.

~~~
crdoconnor
>Yes. Depends on the context.

I can't think of any context where I'd consider spaghetti code clean. It's
exact opposite of clean.

~~~
dave2000
Clean...in the sense that it passes lint, unit testing, continuous integration
etc. Not clean in the sense that "internet user #1209828 approves of its
aesthetics", which is a metric subject to fashion, opinion etc.

------
_ph_
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.

~~~
frou_dh
> coloring your source in all bright colors of the rainbow rather achieves
> [badness]

Low-hanging fruit is the braindead R/G/B/Cyan/Magenta/Yellow used by some
terminals in response to ANSI escape codes:
[https://sdkmvx.files.wordpress.com/2008/08/ansi-
colors.png](https://sdkmvx.files.wordpress.com/2008/08/ansi-colors.png)

In my mind, there's three types of colouring: None, Designed-By-Human, and the
aforementioned Eye-Searing-255 (which should really be killed off or at least
not be the default for _anything_ used seriously). It's disgusting to open
source code using vi or similar and have it presented in Eye-Searing-255.

~~~
teh_klev
> Eye-Searing-255

Lol....this. If your primary workstation OS is Windows then I recommend
grabbing a copy of MobaXTerm. It has the ability to override and tame the
"Eye-Searing-255" beast with its own themes (Solarized Dark and Light, Pastels
etc). No more "oh-my-god-my-eyes" when you open up "ooby-doofer.pl" in vim.

------
prezjordan
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.

------
ggustafsson
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](https://github.com/ggustafsson/Static-Color-Scheme)

~~~
black_knight
For me, it really helps to have code and comments the same colour. That way I
give comments the attention they deserve, and I can resist the temptation to
comment out code.

------
userbinator
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.

------
whack
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.

~~~
coldtea
> _I don 't understand the reasoning behind this. What possible benefit could
> you get from turning off all syntax highlighting?_

He explained his reasoning (and theories why it would work) in enough detail.
You might disagree, but I can't see how you can't understand it.

> _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._

That's the conventional thinking. The whole point of TFA is that it's not
useful -- rather it's distracting, making eyes automatically focus in such
distinctions while losing the bigger picture.

Plus, just because you've colored "language keywords and user specified names"
doesn't mean it's now easier to "visually ignore" one of them while focused on
the other, it can mean the exact opposite: the extra color distraction makes
you jump from one to the other -- unless you put extra conscious effort.

~~~
whack
Yes, I read his reasoning, but I still can't make sense of it. The most common
theme seems to be that having more colors is "distracting". I mean yes, having
more colors gives your eyes more things to process... the same way that 7
letter variable names creates more work for your eyes compared to 2 letter
variable names. But if someone told me that they avoid naming their variables
using complete words because it's too distracting, and only used 2 letter
symbols, I wouldn't understand that either.

From a physics/math perspective, yes, I get that "more" implies more entropy.
Having 4 colors on your screen is more entropy compared to 2 colors. Having 7
letter names is more entropy than having 2 letter names. But if that
additional entropy is used to convey clear, unambiguous and useful
information, it actually makes the overall message simpler. The same way that
long/descriptive variable names make reading code simpler compared to random 2
letter symbols.

On more reflection, the one reasoning I can somewhat understand, is the idea
of handicapping yourself. If you force yourself to type with one hand behind
your back, it gives your brain additional incentive to find concise solutions.
In theory, I guess I understand this line of reasoning, but in practice, I'll
still continue typing with both hands, thank you very much.

Anyway, just thinking aloud here. When I come across something I don't
understand, I try my best to understand what the other side might be thinking.
Not trying to attack anyone... to each his own. Best wishes.

~~~
callahad
I found the Alice in Wonderland image at
[http://www.linusakesson.net/programming/syntaxhighlighting/](http://www.linusakesson.net/programming/syntaxhighlighting/)
particularly compelling, in support of the argument that highlighting may
emphasize syntax at the cost of obscuring semantics.

~~~
jasode
I've not found that Alice analogy colorizing the "verbs" convincing.

With human language like English, we learn it and use it _without the formal
grammar_ ++. A 5-year old child can speak to her mother ( _" I want some
candy!"_) without conscious knowledge of "verbs" or "nouns". A formal grammar
for categorization is what we _layer on top of_ language for analysis in
school. Two people can communicate and understand each other without any
exposure to any grammar lessons. So yes, colorizing verbs looks superfluous
and noisy.[2]

On the other hand, computer programming syntax _starts_ with grammar. You
learn that certain specific tokens are "data types" and other tokens are
"literals", etc, etc. And that grammar categorization in programming languages
_never goes away_ as you're typing out new code. (Otherwise, you'd get a
compiler error or unintended behavior because x="3"+"5" with quotes ("35")
means something different from x=3+5 without quotes (8).) This is why so many
programmers find color highlighting helpful even if they've been programming
that language for 10+ years. Sure we want to focus on higher cognitive purpose
of "semantics" but the grammar is deeply intertwined with _reconstructing_
what the semantics _is_.

A closer analogy of color highlighting in a different realm would be different
colors in TCPIP traces such as "red" highlighting external ip addresses. This
can be helpful for forensics of malware phoning home.

Or in financials dashboards where uptrends are "green" and downtrends are
"red".

The same reasons that colors help the malware analyst or stock trader quickly
parse data at a glance is also how it helps programmers.

++ (at least not consciously that a 5-year old would be self-aware of it. A
theory of innate universal grammar in the brain by Chomsky isn't what I'm
talking about.)

[2] except for rare examples of using annotation or coloring of verbs to help
parse sentences like this:
[https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...](https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo)

------
dave2000
"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.

~~~
masukomi
... sorry but syntax highlighting on spoken languages for parts of speech
would be CRAZY useful when learning to read that language.

------
Pxtl
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.

------
enqk
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/](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.

------
legulere
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.

~~~
paulryanrogers
It can also help when jumping around between many different languages,
especially when they are similar.

~~~
clishem
Interestingly enough, the author of the article notes that it has become
easier for him to jump around different languages.

------
auggierose
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](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.

------
bjterry
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.

[http://i.imgur.com/Q8D9dXz.png](http://i.imgur.com/Q8D9dXz.png)

1: [https://github.com/Fanael/rainbow-
identifiers](https://github.com/Fanael/rainbow-identifiers)

------
mrottenkolber
I do something very similar (grey strings/comments, some bold/underline
identifiers): [http://i.imgur.com/i5j0QKT.png](http://i.imgur.com/i5j0QKT.png)

~~~
kittxkat
I really like that colorscheme, care to share it?

~~~
mrottenkolber
Hmm not sure if this is exactly what you are looking for, but this is the
relevant section in my CUSTOM-SET-FACES:

    
    
      '(font-lock-builtin-face ((t (:weight bold))))
      '(font-lock-comment-face ((t (:foreground "#707470"))))
      '(font-lock-constant-face ((t (:underline t))))
      '(font-lock-doc-face ((t (:inherit font-lock-comment-face))))
      '(font-lock-function-name-face ((t (:inherit font-lock-constant-face))))
      '(font-lock-keyword-face ((t (:weight bold))))
      '(font-lock-preprocessor-face ((t (:underline (:color foreground-color :style wave)))))
      '(font-lock-string-face ((t (:foreground "#707470"))))
      '(font-lock-type-face ((t (:inherit font-lock-constant-face))))
      '(font-lock-variable-name-face ((t (:inherit font-lock-constant-face))))
      '(font-lock-warning-face ((t nil)))
      '(fringe ((t (:background "#ffffff"))))
      '(glyphless-char ((t (:slant italic))))
      '(highlight ((t (:weight bold))))
      '(isearch ((t (:box (:line-width 1 :color "#000000")))))
      '(isearch-fail ((t (:weight bold))))
      '(italic ((t (:slant italic))))
      '(lazy-highlight ((t (:box (:line-width 1 :color "#d0d4d0")))))
      '(link ((t (:inherit button))))
      '(link-visited ((t (:inherit link :box (:line-width 1 :color "#707470" :style pressed-button)))))
      '(minibuffer-prompt ((t (:weight bold))))
      '(mode-line ((t (:inherit mode-line :background "gray93" :foreground "#000000" :height 110 :family "Source Sans Pro"))))
      '(mode-line-emphasis ((t (:underline t))))
      '(mode-line-inactive ((t (:inherit mode-line))))
      '(mouse ((t (:background "#000000" :foreground "#ffffff"))))
      '(region ((t (:background "#d0d4d0"))))
      '(secondary-selection ((t (:background "#e9eee9"))))
      '(show-paren-match ((t (:weight bold))))
      '(show-paren-mismatch ((t (:underline t))))
    

Other than that I use the Inconsolata font.

------
mark_l_watson
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.

------
pjmlp
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.

------
vbezhenar
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.

------
kevinSuttle
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/](http://www.wired.com/2011/01/the-benefit-of-ugly-fonts/)

------
z5h
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.

------
megalodon
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.

------
percept
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.)

~~~
shitgoose
went dark years ago, never looked back.

"one year something changed - I don't know exactly what" \- you matured:)

~~~
percept
Have not--how dare you!

------
massysett
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.

~~~
seanmcdirmid
Comments are like footnotes in a book: great for adding context to the main
text, but they work really well when shoved off to the side somewhere, easily
accessible to those who want them, easily ignored by those just into the main
text (e.g. Author). Unfortunately, code typography is so horrible in our field
that we lack the ability to use the bottom page margin or a side bar for this
purpose, so we hack it up with what's easy: syntax highlighting.

~~~
hga
Comments also lie.

At best, they are a statement that, at the time they were last edited, the
author believed their stated facts were true, or might become so, plenty are
aspirational, "this is what this function or change to it, which I've not yet
written, will do".

He might have been wrong, or the code might have changed without updating the
comment, the actual running code _is the only truth_.

~~~
over
I find that comments at the top of functions are helpful when implementing an
algorithm found in reference material, especially if they have a citation. At
least that way you can check that the function appears to do what the
reference material specifies.

But generally commit messages, descriptive symbols, simple logic, short
functions, and unit tests are better.

------
richard_todd
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.

~~~
jstimpfle

      nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax on \| endif \|<cr><C-g>
      nmap <F12> :set wrap! wrap?<cr>
    

My personal productivity boost :)

------
pklausler
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.

------
agumonkey
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.

------
Pirate-of-SV
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.

~~~
dumbguy
Comments lie, frequently. The only time I need to look a comments is when
someone has done a poor job of naming things. The comments may explain intent,
but they do not explain what it's doing.

Never question someone's credibility because their preference differs from
yours. It'll make people question your credibility.

~~~
iconjack
If your comments lie, you're doing it wrong.

~~~
dumbguy
Not a lot of team experience I'm guessing?

------
api
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.

------
plg
let's have a version for emacs !

------
johansch
"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?)

~~~
cookiemonsta
Yeah, syntax highlighting definitely makes things easier to scan and quickly
process a file in my head.

It also helps with instantly seeing if you are missing a "/' (or used the
wrong one to terminate a string variable), as the rest of the line/file has
the wrong colours.

