3 ms·
I've found syntax highlighting is good at making the structure of code evident, which in turn makes it much easier to grasp the general idea of a snippet at a g
by tikhonj 13y ago
I've found syntax highlighting is good at making the structure of code evident, which in turn makes it much easier to grasp the general idea of a snippet at a glance. This is a very important property!
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
but it's actually rather difficult with normal words infix:
map solve problems `using` rpar rseq
Now compare this to the highlighted version: http://jelv.is/img/hs-syntax-hl.png http://jelv.is/img/hs-syntax-hl.png
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.