The Definitive Guide to Syntax Highlighting | Hacker News Reader

The Definitive Guide to Syntax Highlighting

wilfred.me.uk

77 pointsjgorauskas23 comments

Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's 'A Case Against Syntax Highlighting': http://www.linusakesson.net/programming/syntaxhighlighting/

Personally, I do find syntax highlighting to be useful, but I think it is an interesting dissenting opinion that is worth mentioning. OP's article mentions that Acme doesn't have syntax highlighting, but doesn't really expand on that.

> Personally, I do find syntax highlighting to be useful, but I think it is an interesting dissenting opinion that is worth mentioning.

I just think that syntax highlighting is usually executed really badly, often emphasizing even the least interesting parts of code in the most distracting colors.

The analogy to prose is quite adequate. Randomly highlighting the different word classes in a dozen flashy colors would distract me like crazy; but nobody would argue against using a larger font for headings and a smaller one for footnotes.

If I was programming all day, I would probably spend considerable time creating very subtle syntax highlighting themes for different languages (something like: slate function names, white strings, everything else grey, italic variable names). But I don't, so I usually just turn off syntax highlighting entirely.

Somehow I have never found that essay very convincing.

There is something to be said for clean language design and minimal, a non-distracting editing environment, of course. But the essay doesn't argue the case in any reasoned fashion. It mostly just makes emotional arguments (the talk about training wheels, the example with highlighting fiction, which is over the top).

I have worked with large codebases in plain vi and PFE [1] in my wayward youth. It wasn't exactly what I would call a pleasant experience.

[1] https://en.wikipedia.org/wiki/Programmer%27s_File_Editor

I'm with Linus' side on this - I started writing code without syntax highlighting, and never had any problems doing so. In fact many times I use paper or a whiteboard to prototype some code I'm writing, to mentally step through it and verify that it does what I want it to.

I think much of it has to do with your attitude towards programming languages and source code: do you view them as being intrinsically difficult and thus requiring special tools to handle, or think that they're not any harder than human languages to work with (after having learned and used them extensively) so it feels completely natural to read un-highlighted code like you would text in a human language?

Looking at the rest of his site, you'll find that he has done an incredible amount of other interesting things too, which does increase the credibility of his argument - he doesn't use syntax highlighting, because he doesn't need it to understand his code.

Syntax highlighting is just a tool to eke out a few points of productivity in reading code. I know many people prefer plain text, notepad-style, but some of us like reading typeset documents where formatting (bolding, color, lines) is applied to make the document structure more pronounced.

I think much of it has to do with your attitude toward typography: do you view it as being utterly pointless and devoid of value, or do you like things that don't look like featureless crap.

Anecdotally, I've found that disabling syntax highlighting encourages me to pay more attention to how I structure my code as I'm writing it. I feel more aware of sections of code that may be getting messier as I work.

I still turn on syntax highlighting when I'm reading code though, whether my own or somebody else's.

Better to ask Rob Pike why it doesn't.

From Acme Faq [1]: "No. The creator of main users of Acme find syntax highlighting unhelpful and distracting."

[1] http://acme.cat-v.org/faq

It is interesting to implement syntax highlighters- to solve the problem of making them fast and efficient. In JOE, I save the continuation of the syntax highlighter parser for the beginning of each line. When the user changes the file, the file is re-parsed beginning with the continuation at the start of the line. Parsing stops early if the resulting continuation at the beginning of some subsequent line matches the saved value.

JOE's highlighter supports recursive calls: for example to switch syntax to a scripting language embedded in HTML. Originally I implemented this with template instantiation of the sub-syntax. Recursion is allowed, but to a limited depth: the advantage is that the state can still be represented as a single number.

Later, this was replaced with a real call stack. It turns out that the call stacks of the saved continuations are often identical (stated another way- there is already an identical continuation, so when there is a call, we search for and reuse it if found).

The continuation also includes a buffer for saved data (for example for here document delimiters). The continuation ends up being 32 bytes on 32-bit machines:

  struct highlight_state {
          struct high_frame *stack; /* Closure */
          int state; /* Program counter */
          unsigned char saved_s[24]; /* Local data */
  };

Anyway, it's at least conceptually straightforward to extend this to have any kind of state. Also, it should be possible to compile the syntax parser to the native machine code. Even so, the interpreted implementation is quite fast. Fast enough that there has not been a need to try to run it asynchronously or after a delay as in some other editors.

The article doesn't mention highlighting the declarations/definitions of types & variables. I find it far less obtrusive, and more useful, than lexical highlighting. It's surprisingly easy to do in Emacs, and it works reasonably well across most language modes. Example screenshots: http://david.rothlis.net/code_presentation/distracting_synta...

An interesting and very clear article.

As someone who started in an era when syntax highlighting didn't exist (at least on the machines and tools I was using at the time) I personally like it a great deal.

I found something the other day in the intellij ide's that I really liked (and had not seen before though I may have missed it) which was the ability to highlight the variable under cursor contextually (different for reads and writes).

Like so http://i.imgur.com/u9UkXPN.png

It was a small change but when running through code you've not used/seen before I've found it a nice little touch at getting a good grasp of whats going on with variables.

I've seen more than one talk where the presenter lamented a lack of highlighting based on highly nested structures. So, for example, changing the color based on the closure that one is in. Or, changing the color based on the execution context one is in (so one can make sure they are modifying the variable in the appropriate context).

This would be useful in langues that make heavy use of callbacks such as javascript or scala.

Not sure how hard it would be to implement though - it might require a full parse or compiler pass.

There are actually a few implementations of this for JS, it is an approach that Crockford has championed quite a bit (e.g https://plus.google.com/+DouglasCrockfordEsq/posts/XXkzgJEoE...).

Some implementations that I'm aware of, there may be others:

* http://www.vim.org/scripts/script.php?script_id=4748

* https://github.com/mazurov/sublime-levels

* https://github.com/daniellmb/JavaScript-Scope-Context-Colori...

Parsing is easy to do incrementally, but you could get there just by matching braces. I think Python-like offside rules are better for highlight purposes, however; e.g. see:

http://research.microsoft.com/en-us/projects/liveprogramming...

There is a really great mode [0] for haskell that does the same thing as hl-sexp-mode. Oh and did I mention it fully supports structured editing? These kind of modes really make me question why programs are still written in text instead of ADTs... We don't need to run lexers and parsers to do our syntax highlighting and other fancy stuff... it would be awesome.

[0] https://github.com/chrisdone/structured-haskell-mode

This made me think that it would be useful to have different, easily switchable highlighting modes: syntax and symbols when I'm writing, structure when I'm reading code.

Or maybe syntax highlighting for the scope I'm in and structure for the rest.

I often use the folding/nesting indicators when reading code, it would be an extension of that.

I've been using (and loving) something similar to this while switching modes between code and prose in vim [0]. In addition to changing how syntax highlighting, spellchecking and line breaks happen, there are some other interesting bits specific to prose; like formatting text for pasting into word processors, &c.

[0] http://alols.github.io/2012/11/07/writing-prose-with-vim/

The editor Source Insight had/has this feature, code was in one of two modes, draft or preview. I think that the syntax algorithm was the same, but draft was fixed pitch, syntax colored only, whereas preview had proportional fonts, different sizes and styles in addition to color

I last used SourceInsight circa 2005 so I have no idea about its current status

Does this exist in Sublime Text too? ... color-identifiers-mode, rainbow-delimeters and highlight-parentheses-mode

I believe that Sublime Text is a descendant from Textmate, and therefore uses a single table of recursive regular expressions for syntax highlighting.

It therefore can not distinguish multiple instances of the same thing (different variables) or overlay different highlighting modes on top of one another.

on this note, does anyone know of a way to highlight stuff in #ifdef blocks appropriately within emacs? at the very least if a block of code is within #if 0 ... #endif, it should be grayed out...

The best highlighting is no highlighting at all. Think about it.

You've read that the best programs read like a book. Now picture a book you are reading where the title, subject, nouns and verbs were all colored in some way. Try and read smoothly through that forest and think about highlighting some more.

There are a number of articles about reading on the web and how you highlight links without interrupting the flow of the reader. Should you underline links, or make the word a different color or give it a background? No matter what is done, it's said, you will interrupt the reader's flow and train of thought. Here, though, people exclaim highlighting is beneficial because function names, variables, values, and so on are highlighted and this is good!

Now someone will claim highlighting helps them find a particular value, say a function name but isn't that what indenting is supposed to do? Others will now say it helps with arguments but isn't that parentheses are for?

If you look at most multi-colored, highlighted page of code it looks like a candy store, all of it begging for your attention which is exactly what you don't want. Those with muted colors and grays are no different when you're trying to pick out one slight variation over another and trying to determine if it's a function or something else.

When I read a book, I want paragraphs with indentation and I can read pretty fast that way. So can you. When you read code, you need blocks and indentation (and parenthese/brackets/semicolons). Little else. Maybe nothing else.

I like to think of syntax highlighting as a quick draft-parse. It lets you know how the computer is parsing the code structure. I know, "Code is written for humans to read and only incidentally for computers to execute", but you'd be quite put out if the computer didn't execute your code.

If human languages were written for one more-or-less uniform reader, I'd love a feature that showed how people would resolve pronouns ("Mary gave Sue her laptop.") or ambiguous attachment in general. Granted that's semantic, and probably closer to the feature in some editors where other instances of the same variable are highlighted on hovering, but they are both a form of visual feedback as to how the input token stream will be interpreted. I'd also say it's more important to get that information with a computer, because humans are pretty good at error recovery, and can often resolve syntax errors at the semantic level ("This sentence doesn't make sense; presumably it's a typo and <x> was meant, because that makes sense in context.")

In fairness, I dislike most highlighting schemes, but they definitely have a certain value.

Reply on news.ycombinator.com