4 ms·

A case against syntax highlighting (2007)

4 points by fagnerbrack 3y ago

deleted 3y ago
[deleted]
JackSlateur 3y ago
"I think the idea of syntax highlighting is to clarify the syntax so that the brain can more easily ignore it. Basically, it takes the job of recognizing the structure of the source you're looking it, out of your hands, letting you focus purely on the semantics of the code." Code highlight is a bit like all "typefaces" in this post: some part are big and bold like the sections titles, some parts are in italic. It helps you, not the other way around
gtsop 3y ago
I suggest you put a 2007 tag in the title so people read it in time contexf
jstanley 3y ago
I agree that syntax highlighting is not critical, but TFA mentions 2 cases where syntax highlighting might help: in the middle of long comment blocks (you don't want to be reading commented-out code and thinking it's active), and the difference between "=" and "==". I would add a third, which I run into more frequently than either of those two: Syntax highlighting helps in finding unterminated strings or regexes (why yes, I do write a lot of Perl). If you forget to terminate a string or a regex, a load of the rest of the file turns into string or regex colour, so it's easy to find where you made the mistake.
deleted 3y ago
[deleted]
SuperNinKenDo 3y ago
I'm a little unconvinced to be honest. As one of the other comments here states, syntax highlighting can also be explained as removing the need for parsing syntax as heavily, freeing up mental resources to focus on semantics. Now, whether or not it actually has that effect, I don't know, but it seems like a reasonable belief, and also seems more like it would be the intention behind syntax highlighting in the first place. Though again, I don't know. Furthermore, I'm bot sure that I even agree with the premise that syntax problems are less of an issue than semantic. The number of problems I run into that turn out to be syntax errors feels greater. Particularly thorny ones. Although that also speaks to syntax highlighting's shortcomings. Nevertheless I enjoyed the article because it's good to rethink our assumptions.
DemocracyFTW2 3y ago
The conspicuous thing about this article that rails against colored output is that the author tries to make their point by producing a somewhat contrived counter-example (with natural language text instead of code) that demonstrates their inaptness as a graphic designer even for basic tasks, such as selecting 6 colors including background that go together well. Instead, they choose a light gray background and no less than 3 of 5 hilite colors—blue, yellow, green—that lack any kind of sufficient luminosity contrast wrt the background. Especially the green text becomes just a smushy-washy blob. Based on this I'd rather not believe anything this person says about colorization choices. That, and `(2007)` seriously missing in this submission. [1] https://www.linusakesson.net/programming/syntaxhighlighting/syntax2.png https://www.linusakesson.net/programming/syntaxhighlighting/...

4 points by fagnerbrack 3y ago

deleted 3y ago

[deleted]

"I think the idea of syntax highlighting is to clarify the syntax so that the brain can more easily ignore it. Basically, it takes the job of recognizing the structure of the source you're looking it, out of your hands, letting you focus purely on the semantics of the code." Code highlight is a bit like all "typefaces" in this post: some part are big and bold like the sections titles, some parts are in italic. It helps you, not the other way around

gtsop 3y ago

I suggest you put a 2007 tag in the title so people read it in time contexf

jstanley 3y ago

I agree that syntax highlighting is not critical, but TFA mentions 2 cases where syntax highlighting might help: in the middle of long comment blocks (you don't want to be reading commented-out code and thinking it's active), and the difference between "=" and "==". I would add a third, which I run into more frequently than either of those two: Syntax highlighting helps in finding unterminated strings or regexes (why yes, I do write a lot of Perl). If you forget to terminate a string or a regex, a load of the rest of the file turns into string or regex colour, so it's easy to find where you made the mistake.

deleted 3y ago

[deleted]

SuperNinKenDo 3y ago

I'm a little unconvinced to be honest. As one of the other comments here states, syntax highlighting can also be explained as removing the need for parsing syntax as heavily, freeing up mental resources to focus on semantics. Now, whether or not it actually has that effect, I don't know, but it seems like a reasonable belief, and also seems more like it would be the intention behind syntax highlighting in the first place. Though again, I don't know. Furthermore, I'm bot sure that I even agree with the premise that syntax problems are less of an issue than semantic. The number of problems I run into that turn out to be syntax errors feels greater. Particularly thorny ones. Although that also speaks to syntax highlighting's shortcomings. Nevertheless I enjoyed the article because it's good to rethink our assumptions.

DemocracyFTW2 3y ago

The conspicuous thing about this article that rails against colored output is that the author tries to make their point by producing a somewhat contrived counter-example (with natural language text instead of code) that demonstrates their inaptness as a graphic designer even for basic tasks, such as selecting 6 colors including background that go together well. Instead, they choose a light gray background and no less than 3 of 5 hilite colors—blue, yellow, green—that lack any kind of sufficient luminosity contrast wrt the background. Especially the green text becomes just a smushy-washy blob. Based on this I'd rather not believe anything this person says about colorization choices. That, and `(2007)` seriously missing in this submission. [1] https://www.linusakesson.net/programming/syntaxhighlighting/syntax2.png https://www.linusakesson.net/programming/syntaxhighlighting/...