Syntax Off (2012)

One man's crutch is another man's perfectly reasonable tool. Is a carpenter's level a crutch?

> When I read a book, I don't want parts of speech highlighted in different colours

I have trouble discerning colours and I still use syntax highlighting. I don't think that there are people that are programmers but unable to read code unless all of the floats are purple. The highlighting mostly just tells me "this parsed correctly" and helps my eye track where e.g. string literals begin and end. I don't really see a reason to give either of those things up. If it's distracting, you could easily turn down the theme to just bold one or two keywords and string literals, which solves both of those two problems at least. Maybe go crazy and reverse the background on obvious syntax errors like unexpected symbols.

I rarely want to focus on the code itself and more just want to focus on the problem. Immediately highlighting code errors seems like a perfectly nice thing to do to that end. If I could just write a bunch of code quickly, riddled with syntax errors, and click some magic "okay editor, fix away!" button I'd be fine with that too.

To each their own I suppose.

I do! In long conversations in novels I occasionally lose track of who is currently talking; normally it's really obvious as the next page of text doesn't make any sense until I backtrack to find where the speech got switched, though one time I finished a whole book where my protagonist had the wrong gender because I didn't realise that the prologue and the main text were written from different people's first-person perspectives...

It also reminds me of some anime fansubs, where series with lots of characters would have each character's subs written in their hair colour, which is really helpful for someone who has trouble disinguishing similar foreign voices from each other :P

Which is true, we used to joke that the C compiler on a VAX was so slow that you wanted to be really really sure it wasn't going to throw some crappy syntax error so you read through your code twice before submitting it. But a friend of mine from the Amiga community showed me that iterating fast often lead to faster code development than slower iteration. In both cases having your code in your head made for a better result, but someone who could iterate fast and hold the code in their head, always out performed the person on the slow path.

It can be hard to develop the discipline though.

Whatever metaphor you use, this is just dumb.

Books don't have syntax highlighting, but having never read a book that does, I can't say one way or the other that it is a terrible idea.

And actually, as I think about it more, books would be a nicer reading experience if conversations were highlighted, and if key person/place names where in a different color.

(Just like text in RPGs sometimes).

> "The best way I can describe it is to compare it to reading a book. When I read a book, I don't want parts of speech highlighted in different colours. What I want to do is to read the book, to take in the information."

I would love to try reading a book with the same support. Nouns in red and adverbs in green. It would be fantastic! So much passive information available… Now I think I know what my next weekend project is.

http://en.wikipedia.org/wiki/Synesthesia

This is what my code looked like:

  // Initialise
  for (i=0;i<3;++i) {
    /* Do initialisation here!
    niftyConfig = 1;
    funkyValue = 2;
  }

  // Run forever
  for (;;) {
   /* So, this is where we do stuff! */
  ...
  }

Anything that can increase the chance to catch an error is a good thing.

[EDITED for code formatting.]

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

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

http://www.linusakesson.net/programming/syntaxhighlighting/

I still think it is nutty.

Code is read more often than it's written, but it's skimmed more often than it's read. So making it easy to mentally jump around code without actually reading it is extremely valuable.

I've found this particularly valuable in Haskell because it lets you use arbitrary things in infix position. Now, this by itself is valuable for the same reason: it helps structure the code, neatly separating the operation from its arguments. Some things just make more sense infix. But visually, it's often hard to grasp when something is infix. This is not too bad with operators:

    foo bar baz + qux 11 quux

    map solve problems `using` rpar rseq

The most important part of the above snippet is how "using" divides into two clear parts. And yet, on something like HN, this is a bit hard to follow: "using" looks like another word in a string of words--this is exactly what I want to avoid with the infix syntax!

In Emacs, at least, infix symbols--both operators and names in backticks--get highlighted in a different color. This immediately make the structure of the above code completely clear. Then, when I'm glancing through it, I can focus on the part I care about. (This example is particularly appropriate because the two halves do completely different things--the left one defines the computation and the right one specifies how to parallelize it; chances are I only care about one of the two at a time.)

I think that highlighting operators also explains why I've never had any real difficulties with Haskell's "symbol heavy" code.

This could be extended to a bunch of other structural distinctions I care about. For example, when reading Lisp code, I would love to have macros and functions highlighted differently. Macros generally represent some sort of code organization where functions are often part of the actual program logic; moreover, macros and functions behave very differently.

I vaguely remember somebody posting a lisp-y emacs-y setup of a synth coding environment of sorts that looked like heaven to me. (You'd quickly iterate on code with transforms that would shift the sound playing at all times and the colors would POP at you) It also makes me wonder how blind coders handle things. Does a pleasant yet distinct background noise when hovering over say, curly braces or parens, does that make sense to anybody else? I'm developing an itch here but I don't want to go it alone as it were.

Edit: also come to think of it, why isn't this stuff empirically tested? The right font faces and sizes for optimal readability, tabs vs spaces, camelCase vs snake_case, colors and which ones, all the classics. Where is the science?

I found this interesting, as my reaction has been almost the complete opposite. I've never felt that syntax highlighting played a part in understanding code at a high level. Syntax highlighting is there for when I'm reading my code like a copy-editor. It (along with an inline linter) is there to make syntactical errors more obvious so I can deal with them as I make them.

On the other hand, perhaps highlighting the syntax is to represent the structure of source code, or make it more readable. There is also a text highlight utility for text, called BeeLineReader (http://www.beelinereader.com/)

Personally I program Clojure, so there's not a lot of syntax to highlight--well, more than in scheme, for example--but I couldn't imagine life without brace matching (a dynamic kind of syntax highlighting).

Once you're used to the lack of color, go all the way and use a proportional font.