Re:The impact of syntax colouring on program comprehension [...
by kazinator on Friday November 27, 2015 @12:45AM
(#10636037)
I wouldn't even think about releasing a programming language without an accurate syntax coloring definition for at least one major editor, maintained side by side.
Looking at code without coloring is like looking at a road atlas that has been photocopied in black and white.
Even some grayscale cues are better than nothing.
I actually run the Vim editor dynamically out of Apache to colorize TXR files. You can see that here and here:
The second example shows a mixture of two languages: a Lisp dialect and an extraction language. Both have their own sets of standard symbols (which intersect: there are some symbols in common). They are correctly rendered in a different color: the Lisp words are green, and the extraction language words are burgundy red. This kind of thing is very helpful.
The Vim definition I maintain is quite accurate --- and not only for correct programs. I stuffed in rules so that errors are boldly flagged. For instance, even little things like using an undefined escape sequence in a character string or regex literal. (And it knows the exact set for all literals.) This works remarkably well; hardly any typos I make get by it.
Syntax highlighting definitions also help with formatting;
they provide the editor with nesting cues for indentation.
Working without this stuff this day and age is completely silly.
Looking at code without coloring is like looking at a road atlas that has been photocopied in black and white.
Even some grayscale cues are better than nothing.
I actually run the Vim editor dynamically out of Apache to colorize TXR files. You can see that here and here:
http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/struct...
http://www.kylheku.com/cgit/txr/tree/tests/010/align-columns...
The second example shows a mixture of two languages: a Lisp dialect and an extraction language. Both have their own sets of standard symbols (which intersect: there are some symbols in common). They are correctly rendered in a different color: the Lisp words are green, and the extraction language words are burgundy red. This kind of thing is very helpful.
The Vim definition I maintain is quite accurate --- and not only for correct programs. I stuffed in rules so that errors are boldly flagged. For instance, even little things like using an undefined escape sequence in a character string or regex literal. (And it knows the exact set for all literals.) This works remarkably well; hardly any typos I make get by it.
Syntax highlighting definitions also help with formatting; they provide the editor with nesting cues for indentation.
Working without this stuff this day and age is completely silly.