A case against syntax highlighting (2007)
linusakesson.net
linusakesson.net
That might be true for text, but I don't read code at all the way I read prose. I highly doubt i've ever read more then four or five lines of code in a row without my eye jumping to other parts of the function, forward to the next part to understand why variables are being set up, or backwards to remember when such variable was defined, or jumping to the big picture to remember how this function or that fits into the overall program. Syntax highlighting is enormously helpful to my eye when reading in that manner.
It's an opinion piece, but you and just about everyone in this thread is writing as if their opinion is a fact that trumps his opinion. Stop that :(.
Edit: Why the downvotes? Are different opinions really that bad?
I learned most of what I know on a Solaris 9 machine on a CRT with a model m back in 2008 with zero syntax highlighting, in vi and without vim. Zero fluff. I've tried syntax highlighting, but every time I do, I end up going back and my code quality and readability improves. I imagine a similar effect would happen to others if their colors were changed to incredibly tacky colors.
The very first opening line is an argument against syntax highlighting. Arguments (at least, of this sort) should be based on facts or studies, or at least logical reasoning and it is not introduced as an opinion piece, but an argument.
I only gave the article a glance and I take two issues with it.
>Syntax highlighting applied to fiction. It's easy to spot all the verbs, but why on Earth would you want to do that?
I wouldn't need to for English, however I can think of a situation where I'd like to see the difference between an int '5' and a string '5' at a glance. In fact - that sort of bug isn't all that uncommon in languages that aren't hard typed.
>[misguided piano teachers, yellow keys]...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.
This argues like a case against mnemonics as learning devices. Mnemonics are an entire memory trick designed to be "un-learned" by the learner. Planet names aren't difficult to learn but a sentence like "Mercury Viewed Earth’s Many Aspects Joyfully Sitting Under Neptune" sure makes the order from the sun easier to remember. Mnemonics are a pretty well-research thing and they work [0]. Most people who want to compete in memory contests rely on using them. My favorite example is the Major System [1].
For me, syntax highlighting is a crutch that I want to avoid. I find myself glancing at my code rather than actually reading my code when it's enabled. It's an incredibly refreshing feeling to turn it off and just go back into vi. My code becomes shorter, easier to read, faster and much easier to maintain.
Setting that aside, though, the author is not just expressing his opinion. This piece isn't saying, "Well, personally, I don't like syntax highlighting." The OP is arguing for a general truth, not just a personal preference of the author. The piece makes objective claims about the effects syntax highlighting has on its users. Why shouldn't people feel entitled to say the argument is flawed if they see flaws in the argument?
Really, I just think the guy's just very opinionated and is expressing something that's very important to him. Principle of charity and all that.
The big difference between genuine reading and coding is the variability of scanning / focus. When you read, you usually want to take it all in -- it wouldn't make sense to jump around because it's a single, linear journey.
Code does not observe this rule, so the more experience you get as a coder, the better scanner you become. You quickly view a class and think "ah yes yes.. it's _roughly_ doing this.. that" -- you sure as heck don't read the whole thing carefully word by word! The best coders are amazing scanners -- capable of pointing out a missing parenthesis in a sea of parenthesis. This argument against syntax highlighting is like taking the batteries outta our flashlight. Sure, we'd be more careful but our productivity would surely suffer.
Feel free to keep doing what you're doing, but making assumptions about workflows that you're unwilling to try is not helpful or convincing.
I also question that you indeed are a faster scanner. Here's a specific example I wonder if your scanning would win out on -- Xcode turns internal Cocoa classes blue whereas your own classes are green. You quickly know what you coded and what you didn't. Not helpful? Should already know? I wonder if you inherited someone else's code base if you would enjoy the green immediate feedback rather than the inference you would otherwise have to take.
When working without highlighting, I rely on the shape of the code's text and the search function of my editor to navigate as I jump around code. With syntax highlighting, I have those tools, and extra navigational cues provided by little islands of color.
I haven't noticed a difference in my scanning speed or code comprehension between the two. It may be there, but I'm not conscious of it. Consciously, I've got a slight preference for the colorization. It makes the code feel "friendlier", and I'm happier to be looking at it. The un-highlighted environments tend to be older Unix machines with other annoyances in the operating experience, so I'm sure that plays a lot into my perception.
Programming language keywords are different than English verbs. If you misspell keywords, your program will fail, but if you misspell a verb in an essay, nothing catastrophic happens, most of the time.
It does take me longer to read code in an uncolored ssh window than in Sublime with syntax highlighting, that's true. And I agree that semantics are more important than syntax. But I'm not sure I buy that having highlighting makes reading colored code slower than it would be otherwise. The case here didn't present evidence that it's worse. It might be a crutch, but it's also possible that the reason reading uncolored code is slower is because having syntax highlighting is actually better than not having it.
Misspelling English doesn't usually cause a complete failure, or force you to try again, that's my point. The example in the essay was a cute comparison that I think actually is worth considering, but is ultimately comparing apples to oranges.
But, no matter how fast your compiler is, the cost of finding and fixing a mis-spelling in your editor with syntax highlighting is much less expensive than finding them and fixing them with a compiler or by executing the program. Could be a few seconds per typo less expensive, but my professional experience has generally involved builds that take 1-10 minutes. I'll take the syntax highlighting crutch over waiting for my compiler to fail.
Change one character in one file that gets linked at the end of the build, the syntax check would go from 7 minutes to 3.5 on average - still too slow. You're also overlooking conditional compilation, your change might break the build on another platform - the syntax won't be checked until it hits the buildbot that flips the right flags.
> Non-trivial projects in better-designed languages...
Ah, the lets redo-everything-in-x school of thought - good luck with that.
Syntax highlighting is helpful to me for the following purposes.
1. Scanning through code.
2. Making it clear what is a comment, what is a string, and what is code.
3. Catching a variety of minor syntax errors automatically. (For example failing to properly close a multi-line quote...)
4. When switching languages, reminding me when I didn't fully switch gears and wound up using the wrong keyword.
I learned to program in vi without syntax highlighting. Before I tried syntax highlighting, I thought it was silly. After I tried it, I found it made for a more comfortable environment. The difference isn't huge, but it is noticeable enough that now I always turn it on.
There are times when I log into a system to edit something with vim, and no syntax highlighting appears. It surprises me, but not a deal-breaker.
I also thought syntax highlighting was unnecessary. The first time I saw a video of using the Twilight theme for Sublime, I was stunned by what the colors brought out. At that time, my awareness was not as developed, so I couldn't even tell you I liked it because of how I experienced the code.
So I spent a lot of time finding good themes for my editors, first vim and now spacemacs. If I am going to look at code all day, I don't want my eyes to bleed. Aesthetics is the strongest argument I have for syntax highlighting, and it should not be casually dismissed without investigation.
It sounds stupid, but it matters.
Varying styles within a work can be immensely helpful, and is almost universally done. For example, headers tend to be written bigger to indicate a) that they're something different from the main text, and b) what their relationship to the main text is. Similarly, italic and bold text are used to impart additional meaning to various parts of the text. Many publications will use a different style for things like bylines and photo captions — again, because they are different things from the body text and this helps the reader pick out the parts of the page in a purely visual manner. It's even common to see parts of the body text stylized differently to indicate that they have a special function — for example, in a Q&A format, you'll often see the questions formatted differently from answers, or the identities of the speakers might be written differently from the words they said.
So not only is this philosophy about typography not necessarily applicable to code, it's not even widely accepted for ordinary written text.
"Perhaps syntax highlighting was invented to speed up the reading process. ... 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"
and then believe the rest of the article. Well, I don't believe that part, since I experience the complete opposite every day. A silly typographical guideline doesn't affect my experience at all.
Right, because prose text never uses more than one type size, treatment, or formatting to make the content easier to read.
"A case against traffic lights having colors. You should just pay more attention to what each dot means"
I like syntax highlighting it, it helps me. Not some over the roof-rainbow colors, I always like minimal and dark color schemes, but I think it would definitely feel weird to code without syntax highlighting. Although I would get used to it. But if it ain't broken don't fix it.
Pick up any reference book. A dictionary, a textbook, a phone book, whatever. Leaf through it a bit. You'll find they all use text formatting to highlight things. The dictionaries I've used typically use bold for a word and its different forms, italics for parts of speech, and such. Phone books similarly use different weights and sizes for names, addresses, and phone numbers. Textbooks use bold and italics to highlight important terms and concepts and students will often mark up the books to further highlight certain things.
Code is usually not meant to be read like you would a novel; it's much more like a reference text. For me, at least, syntax highlighting is a tool that supports the ability to more easily find what I need and understand it in isolation. Maybe it would be slower for me to read a syntax-highlighted file token-by-token end-to-end than an un-highlighted one but that's not a use case I ever need.
I've not found the Alice-in-Wonderland analogy colorizing the "verbs" to be 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 experienced 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...
Best color scheme I have found, I use it for everything. I can't even imagine opening up some of my code in notepad or vi(m) with no syntax highlighting and actually trying to do a productive amount of work. This suggestion seems absolutely ridiculous if your syntax highlighting is sane.
Really? Why is it then that we have such popularity in color schemes like Solarized[1]? Or the much older zenburn? I'll agree that there are a lot of bad color schemes out there, but that's because anyone can create a color scheme. There's no certification process to create one.
Back in the era where people "themed" their window manager (GNOME, Kwin, Windows, and even OSX had hacks for this), look at all of the really gaudy window themes that were created. Is this an argument against all theming of windows?
Is judicious use of Comic Sans an argument against fonts? Of course not.
https://en.m.wikipedia.org/wiki/Rubric
Also this claim isn't even correct - code which varies in color is not changing typeface! Really it's no different from using bold or italic in traditional prose, which nobody would complain about.
^Ocomment.txt^X
Does vi support it, though? I know vim does.
http://stackoverflow.com/questions/19444340/how-to-specify-s...
In fact the only text editors that I know of off the top of my head that do not support syntax highlighting is notepad and pico.
I will take that experimental data over a pile of arguments from first principles any day.
Fixed that for you.
I agree. However, I don't see how syntax highlighting necessarily makes reasoning code easier or harder. I don't know if the arguments are specious, but I think and feel that much of the arguments in the article are weak and unconvincing.
The author has already dismissed (without examination) the strongest argument for syntax highlighting: aesthetics. There are whole philosophies of aesthetics that makes a lot of sense, but only when we go beyond the mere results of the programming. The aesthetic argument for syntax highlighting isn't for the sake of the quality of the resulting program but rather, the quality of the experience for the programmer. That in and of itself is underestimated by a fixation on the resulting code.
There are philosophies that precisely define aesthetics, but these are generally in the non-dual philosophies, not the dualist philosophies. As soon as you have a dualist philosophy, you set up an opposition between privileging objective over subjective, or subjective over objective, and it resolves nothing. Non-dual philosophies do not privilege objective over subjective, or subjective over objective, and have a lot of useful, testable (empirical, experienceable) things to say about aesthetics.
Aesthetics bring a human perspective to the technology and reminds us that, however efficient a technology is, it shapes and is in turn shaped by our experiences as human beings.
Like others I find highlighting useful for code editing, and agree with the implication that syntax plays a much bigger role in coding vs. reading non-code text. IOW semantics of code is obviously far more dependent on syntactic precision than in ordinary use of language.
Finally, the universality of syntax highlighting in code editors is unlikely to be due to degenerate comprehension skills among programmers. Rather it's implicit evidence that highlighting provides substantial productivity benefit to code writers.
Recently somebody posted microlight.js (https://asvd.github.io/microlight/) which has exactly the type of colour theme I'm looking for. Only comments and strings are highlighted, anything else is the default font.
So I've hacked together in 10 minutes a rough emacs theme, not satisfied yet, looks like this: https://www.dropbox.com/s/p41iw7r5p4dwd4w/Screenshot%202016-...
So my questions are:
1) Anyone know a good minimal theme for Emacs?
2) How do I change the emacs font lock for operators/braces? There only seems to be a hacky way to do it.
Current as opposed to what though? People have always created themes that work for some people, but not for others. I've even seen themes that used bold, underline and italics rather than color to "highlight" syntax.
Without syntax highlighting, I have to keep the contextual meaning of every character I read in state mentally, and constantly update the mental map I have of the code. I have to actively parse every character.
With syntax highlighting, the relationship of each token to the rest of the tokens around it is preserved, so that meaning is inferable rather than needing to be maintained in memory. I can scan and jump around between meaningful code anchors without having to read every line of code between. It's like getting to jump straight to the AST.
To each their own, of course. I started programming without syntax highlighting and the switch made me a faster dev without question.
Also, it seems to me that the author has bigger problem with the way syntax highlighting is implemented than the concept itself. I would agree there's much to be improved in syntax highlighting, in a way that would actually help programmer and draw attention to problematic constructs. This would require collaboration between editor and different tools, but it would be a good step forward I think.
Why the negative comments with some folk even calling this guy wrong on an opinion piece? Sheesh, people..
The author obviously hasn't spent much time coding.
I take it that you didn't look through his list of projects. There are some impressive things listed.
So specific color for variables in specific scope that carries over to nested scopes where the variable is used.
Less strain on the brain, so to speak.
I just don't see an actual reason not to use it, but if you don't want to, knock yourself out I guess.
Syntax highlighting has so many obvious benefits that I think there's only two types of people who are against it; the first is people who just don't use it and use it as a silly point of pride that they don't and the second is people who are just trolling.
While you're typing things get highlighted the correct color indicating your syntax is correct. For example, you aren't going to forget a quote to end a string (or start a string) if all your code gets highlighted the wrong color. This alone is enough to make it worthwhile even if syntax highlighting didn't do anything else.
I'm not gonna waste a lot of time here listing out the numerous benefits of syntax highlight but instead make this point; the same dumb argument could be made against indentation. Why do you need to indent?! You should understand the code by reading it not based on indentation!
Yeah, that's really stupid isn't it?