I'm confused. This article is about syntax highlighting, not semantic highlighting. Do you have semantic highlighting set up.or syntax highlighting? If the former, what are are you using?
It's an unfortunate comment since I struggle with word salad most days. Being able to skim and find certain blocks or aspects of a source file is preferable if I can't remember the name of something right away.
I'd have to add coloring strings and language keywords to the list of exceptions before trying this. Strings are (imo) an obvious necessity, but I can't tell you how many times I've stopped myself from naming a variable a reserved keyword because it showed up visibly differently when typing it out.
I'm generally favorable to giving up syntax coloring. I do agree with the OP that it distracts without adding much benefit. I want to recognize the intent, over the syntax. I do usually program in Lisp/Scheme/Racket, which are syntactically simple though, and use Solarized which is lower contrast than some. So both the distraction and benefits are less.
I guess the main benefit I feel I'm getting now is string highlighting and comment dimming. Parens stand out to my brain anyway so I don't think I am benefitting from their being colorized.
>"Syntax highlighting is a standard feature of most modern text editors"
Sorry it was a standard feature in some IDE's like forever. Nothing is modern about it except the fact that the amount of what being recognized and made visually different did increase thanks in good part to language servers.
As for giving it up - well for what I care they could still use punch card, their choice. For me - I would not give it up.
Lots of people here are old enough to remember when syntax highlighting wasn't standard. Also the article itself is old (2007), and syntax highlighting, though common, was not as ancient, standard or varied then as it is now.
I am definitely old enough (60 years). Yes it was not standard in industry say in the 90s and I have to admit I was incorrect in this sense. Still it was available in some IDEs. Like Turbo Pascal had it since 1992.
I have a strange use case for syntax highlighting: If you ever forget to close a string or a function definition argument list, or anything along those lines, the following text will not be colored as usual. This is also why I have automatic indentation enabled, if the indent is put in the wrong place, I know I made a syntax error further up.
In many (most?) languages, you can look at where your code stops being colored and see you forgot to close something like a comment or a paren.
Depends on the language, depends on the syntax highlighter. I've seen syntax highlighters that don't make un-terminated python strings look wrong, because the highlighter knows that strings can't span multiple lines (others will give a red squiggly). Some languages give really cryptic errors about the next line -- which gets you in the right neighborhood, good enough for me, but not so friendly for newbies.
I don't know about the person you're replying to, but I'm still old school and don't integrate compiling with my editor; maybe some day it will use a language server and get that for free, but for now it's just language specific configuration that does an OK enough job. When I write a string and the rest of the screen is string colored, it quickly notifies me that I messed up something.
It depends on the compiler or interpreter. Some don't give very informative messages and indicate a syntax error on a line that may be one or more lines after the actual error. But the syntax highlighting gives an immediate indication that something isn't right.
I'm not convinced, but this is an interesting take.
The selected examples are unfair as they use a badly contrasted foreground color against a white background which break all the WCAG Guidelines for contrast. IDEs should use colors with an accessible contrast ratio.
#00dd00 (green) -> #ffffff: 1.85:1 - fail on all results
#00dddd (cyan) -> #ffffff: 1.70:1 - fail on all results
I feel another exception would be the differentiation of static, member and local variables as an additional IDE-based hint, on top of naming conventions.
This hardly makes a case at all. Only one section in the middle is actually dedicated to why syntax highlight is bad and it boils down to a baseless assertion about "biasing" the developer's mind toward syntax. I would counter that assisting developers in thinking about how code will be interpreted or compiled rather than bytes of text is closer to the semantic meaning than without.
There's also a comparison to highlight syntax in fiction, which is absurd for many reasons. A simple one being that the _goal_ of fiction can often be to obscure meaning for the sake of ambiguity. I'm offended not by the thesis but by the presumptuous nature of the argument.
I started programming the C64, then moved to Turbo Pascal 3 for DOS, then Turbo Pascal 6. None of these environments provided syntax highlighting. Then came Borland Pascal 7, with syntax highlighting... And, boy, I was mesmerized!
I really cannot think of going back to plain two-color editors like TP3. Syntax highlighting helps me to spot unterminated strings, mistaken variable names that clash with keywords, plus the general "feeling" of a page of code that I get when I quickly scroll a long source file in search of a specific place.
I do not think that syntax highlighting has spread everywhere just because it looks cool. It is SOOO useful!
The problem in the example is excessive contrast that interrupts the visual connectivity of related elements. Stop using party-colored themes and the highlighting is less objectionable
This is a very good point. Excessive highlighting can be distracting by itself. I try to keep it to a minimal - colors that are close enough, as well as using bold so that the flow of reading isn't broken.
Also, avoid RGBi colors. They are horrible, period.
Good point: no-syntax highlighting is just syntax highlighting in one color, with no computation time spent to perform it. What the situation really is is that there are a variety of ways syntax highlighting can be done--not just the colors, but how fine-grained you want to be. Blanket statements like "syntax highlighting is bad" just don't make sense.
Skimming code is a legitimate task. At a large/FAANG company you will often have a 400k sloc code base and only a vague idea which bits of code you need to study more intensively to find out what you need.
Syntax highlighting is more than the article is mentioning, it seems author comment is focused on old highlighters. Once when you get used to one theme brain is not even noticing, unless as shown in example colors are highly offending to aesthetic (the one in the article is hurting my brain). In modern editors as VSCode there is a huge range of adjustments.
Nowadays we can do more than just see what are commands, keywords, increments ... we can see unused variables/import, mistyped variable, see bracket that are not closed, comments, etc.
I've been programming since before syntax highlighting was common, and I continue to program without it frequently enough that I'm happy to not rely on it. I'd rather spend my time programming than figure out how to get colors working in the terminal session in. What I like is to be able to get work done in any situation. Reliance on any given tool is an impediment to that.
Not to say that I hate syntax highlighting. Likewise: I carry a lighter camping, but I also know how to make and use a bow drill. I think there's a big difference between learning to live without a technology, and hating that technology. And that's the generous read of this article.
To rebut the author, I've seen an indisputably good use of syntax highlighting: rainbow-colored parentheses in emacs. In most languages, I've got a sixth sense for unmatched parens, braces and brackets -- but that isn't strong enough for lisp.
How do I disable syntax highlighting in JetBrains IDEs? I can choose all kinds of color schemes, but there is no predefined "Plain" color scheme. I would have to create a new scheme and go through each syntax element and reset the color manually.
1 helps with typos , I will notice a weird color and probably underlines if the variable or function is undefined so I can fix the issue before it crashes somewhere in the future
2 also helps me when it highlights unused stuff, shows me that a refactor or a merge happened and it needs a closer look
3 we put JSDoc type documentation and colors will look different if say you used a method on an object that does not have such method or member defined
I create my personalized color schemes that fit me and my disabilities so I don't care if maybe it does not work for someone else or if soem dude tested on some students and observer some small effect or even worse some designer decide how my stuff should look because he read some blog posts from his guru and now he thinks he is a UX master.
I suggest people try a good IDE, tweak things, I always notice bugs in my colleagues code that a good IDE would have prevented them.
Independently of anything else, I find the additional distinctiveness created by syntax highlighting helpful for keeping my place, or recognising where I am, if I scroll around a file quickly.
This article is very interesting. I recommend everyone who reads this to try and dissect what makes a wrong argument sound convincing.
A ton of terrible arguments are made here: X is important so Y is not important. ABC is a sacred rule that must be followed without question and doing XYZ does not follow the sacred rule. Wrong thing is done to help dumb people so smart people shouldn't do wrong thing.
To me the flaw was "you shouldn't do X in the case of Y therefore you shouldn't do it in the case of Z" the assumption being that Y and Z are similar, but in reality they aren't.
I'm not actually very convinced by the article, though I don't entirely disagree with it either; I've never been syntax highlighting's biggest fan, and never bothered to tweak it myself. But "the compiler checks it" doesn't mean I shouldn't care about it, and "it doesn't work in fiction" is just totally irrelevant.
The only test is: does it work for you? For a long time, I thought it didn't do much for me, but recently I discovered that highlighting used and unused variables/functions differently helps me find typos, and clean up my code. Comments obviously should be a bit muted. And strings are nice. I don't care much about highlighting keywords, but it doesn't bother me either. I think highlighting the parameters of the function I'm in differently than the rest of my code would help me, but I don't think my IDE does that by default. Maybe it's time to start tweaking my code highlighting.
I can't stand syntax highlighting. I mean literally -- I can't read code that is displayed using syntax highlighting, and when someone tries to force me to, I can't understand it. When someone ask for my help with a piece of code, I have to ask them to turn the highlighting off (which in some editors is harder than you think). I normally use acme, which doesn't even have syntax highlighting, but it bothers me to no end that on some (many? all?) Linux distributions vim comes by default with syntax highlighting on. Fortunately BSDs come with nvi, which also doesn't have syntax highlighting.
Unfortunately, most blog posts and documentation on web sites spam syntax highlighting in my face. For those cases I copy the code in my editor to read it which also has the benefit of allowing me to see it with proportional fonts. I use proportional fonts for my programming.
I don't know, I don't think so. I am very sensitive to the color and quality of light, for example I imediately see the metameric failure caused by crappy (99%) of LED lights and I spent months finding some good LED-based lightbulbs.
One hypothesis that I came out with might be that advertising competes for my attention using lots of colors, and I have become very experienced in tuning out any kind of advertising. I don't consciously associate colored text with advertising, but for whatever reason the mechanism seems to be active in my brain.
Sometimes color highlighting actually serves as an objectively beneficial function, for example colored grep output or colored diff output. Even in those cases I still have to turn colors off, otherwise I simply skip past the important bits of the text that are highlighted.
colorblind. absolutely hate syntax highlighting. I don't understand how you can read text that changes contrast every few characters - but obviously it looks different for everyone else.
Yeah the logic does not follow that highlighting prose means highlighting code is bad.
I think the main benefit to highlighting code is it’s one less task my brain has to do, freeing it up to think about the structure of the code in writing and the bigger picture.
Searching your code for that our of place ‘ is no benefit to anyone.
Agreed, but structure is prose is important too. Who wants to read something that is not broken into paragraphs, has not capital letters to indicate sentences, etc.
Some language teaching software does use syntax highlighting for specific lessons. Rosetta Stone at least does, where it specifically highlights things like noun/adjective agreement, verb conjugation agreement with pronouns and names (io pago, capello rosso [italics for highlighting since we can't color text here]). And then we use various types of brackets, bold, italic, dashes and commas, and other things to isolate what we write. If I want to emphasize something, on HN, I use a pair of asterisks around the text: *emphasize*.
We use all sorts of typographical conventions to draw attention to the things we want emphasis drawn to or to encode some notion. In many novels, in English at least, a character's thoughts are italicized rather than quoted. The noir detective might be found at his desk thinking, I knew I'd seen her before, but no name came to mind. In textbooks you have a mix of bold and italics used to identify specific kind of content. Bold for new keywords students of the book should keep in mind, usually adjacent to a definition. Italics might indicate a name assigned to something: Using the pumping lemma we can...
Perhaps in our code editors we've overdone highlighting, or coloring could be a poor (certainly for some colorblind readers) method of highlighting, but syntax highlighting itself can make a great deal of sense.
It's worth considering that in the examples from prose, we usually don't draw attention to syntax, but to semantics. What does the thing with different typography mean, why is it given that special formatting or why is it surrounded by special brackets, dashes, or quotes. We don't highlight (as in the example in the article) nouns one way, verbs another, adjectives a third, and adverbs a fourth. Or verbs different ways depending on the tense or number. We highlight individual words in some manner to bring attention to them, or groups of words to indicate their logical separation in some sense from their surroundings.
When you’re reading a book out loud to a child one thing that matters is who is talking (so you can do their voice) so colour-coding characters would be nice!
It might help identifying arguments. It's a huge cognitive load to identify the premises and the conclusion of an argument.[0] I've seen quite a few philosophers using text markers to help themselves navigate through arguments in prose.
Yeah, but that’s not syntactical structure. When you read prose you aren’t thinking about subject, verb, and predicate, because semantics are far more important.
You hit the nail on the head. The author seems to be saying syntax coloring is bad, because you don't do it for prose. But you read code differently than you read prose.
Syntax highlighting also doesn't make you focus only on the syntax. That is just absurd. It actually does the opposite. You actually play less attention to the syntax.
As an experienced coder syntax highlighting makes my job easier
93 comments
[ 3.1 ms ] story [ 164 ms ] thread"moves focus from content to form", if data drives your code structure, especially easy with functional langs, these two start to become isomorphic.
It's an unfortunate comment since I struggle with word salad most days. Being able to skim and find certain blocks or aspects of a source file is preferable if I can't remember the name of something right away.
I guess the main benefit I feel I'm getting now is string highlighting and comment dimming. Parens stand out to my brain anyway so I don't think I am benefitting from their being colorized.
Sorry it was a standard feature in some IDE's like forever. Nothing is modern about it except the fact that the amount of what being recognized and made visually different did increase thanks in good part to language servers.
As for giving it up - well for what I care they could still use punch card, their choice. For me - I would not give it up.
In many (most?) languages, you can look at where your code stops being colored and see you forgot to close something like a comment or a paren.
Wouldn't the compiler find this and the editor mark it as a compilation error?
Syntax highlighting happens in real time. Compiling (at least in my editor), only happens when I say it should.
(I mostly agree with you. My preferred syntax highlighting is for just comments and string literals.)
I’d never lecture someone on whether they have syntax highlighting like the blog post does. It’s dumb to argue personal preference as if it’s fact.
I'm not convinced, but this is an interesting take.
The selected examples are unfair as they use a badly contrasted foreground color against a white background which break all the WCAG Guidelines for contrast. IDEs should use colors with an accessible contrast ratio.
#00dd00 (green) -> #ffffff: 1.85:1 - fail on all results
#00dddd (cyan) -> #ffffff: 1.70:1 - fail on all results
I feel another exception would be the differentiation of static, member and local variables as an additional IDE-based hint, on top of naming conventions.
There's also a comparison to highlight syntax in fiction, which is absurd for many reasons. A simple one being that the _goal_ of fiction can often be to obscure meaning for the sake of ambiguity. I'm offended not by the thesis but by the presumptuous nature of the argument.
I really cannot think of going back to plain two-color editors like TP3. Syntax highlighting helps me to spot unterminated strings, mistaken variable names that clash with keywords, plus the general "feeling" of a page of code that I get when I quickly scroll a long source file in search of a specific place.
I do not think that syntax highlighting has spread everywhere just because it looks cool. It is SOOO useful!
Also, avoid RGBi colors. They are horrible, period.
With syntax highlighters can be applied same rule as with UI, pleasing interface make it more usable. https://www.nngroup.com/articles/aesthetic-usability-effect/
For me syntax highlighting hate is nothing more than luddism.
I think my favourite was surrounding each mutex lock/unlock operation with lines of %-characters.
Lovely.Your mutex_lock(&mutex) will be colored exactly the same as any arbitrary foo(&bar), so you’d still want to call it out somehow.
Not to say that I hate syntax highlighting. Likewise: I carry a lighter camping, but I also know how to make and use a bow drill. I think there's a big difference between learning to live without a technology, and hating that technology. And that's the generous read of this article.
To rebut the author, I've seen an indisputably good use of syntax highlighting: rainbow-colored parentheses in emacs. In most languages, I've got a sixth sense for unmatched parens, braces and brackets -- but that isn't strong enough for lisp.
stupid whoever downvoted you.
1 helps with typos , I will notice a weird color and probably underlines if the variable or function is undefined so I can fix the issue before it crashes somewhere in the future
2 also helps me when it highlights unused stuff, shows me that a refactor or a merge happened and it needs a closer look
3 we put JSDoc type documentation and colors will look different if say you used a method on an object that does not have such method or member defined
I create my personalized color schemes that fit me and my disabilities so I don't care if maybe it does not work for someone else or if soem dude tested on some students and observer some small effect or even worse some designer decide how my stuff should look because he read some blog posts from his guru and now he thinks he is a UX master.
I suggest people try a good IDE, tweak things, I always notice bugs in my colleagues code that a good IDE would have prevented them.
The main reason why I use syntax highlighting is because I'm use to it and it looks cool.
* based on Acme http://acme.cat-v.org/
In 2007, I might have agreed.
In 2021, I've added syntax highlighting to my own editor (and things feel harder without it).
A ton of terrible arguments are made here: X is important so Y is not important. ABC is a sacred rule that must be followed without question and doing XYZ does not follow the sacred rule. Wrong thing is done to help dumb people so smart people shouldn't do wrong thing.
The only test is: does it work for you? For a long time, I thought it didn't do much for me, but recently I discovered that highlighting used and unused variables/functions differently helps me find typos, and clean up my code. Comments obviously should be a bit muted. And strings are nice. I don't care much about highlighting keywords, but it doesn't bother me either. I think highlighting the parameters of the function I'm in differently than the rest of my code would help me, but I don't think my IDE does that by default. Maybe it's time to start tweaking my code highlighting.
Unfortunately, most blog posts and documentation on web sites spam syntax highlighting in my face. For those cases I copy the code in my editor to read it which also has the benefit of allowing me to see it with proportional fonts. I use proportional fonts for my programming.
One hypothesis that I came out with might be that advertising competes for my attention using lots of colors, and I have become very experienced in tuning out any kind of advertising. I don't consciously associate colored text with advertising, but for whatever reason the mechanism seems to be active in my brain.
Sometimes color highlighting actually serves as an objectively beneficial function, for example colored grep output or colored diff output. Even in those cases I still have to turn colors off, otherwise I simply skip past the important bits of the text that are highlighted.
Syntax highlighting is about understanding structure.
I could blur out my editor to the point where I could not make out individual letters and still understand the code structure.
When reading prose you don’t care about structure, especially not in English (in latin languages structure is way more important).
It’s important to have a good highlighter though. STM32cube IDE has a very bad highlighter that gets confused sometimes.
I’ve seen people chasing simple bugs for far too long just because the highlighter was broken.
I think the main benefit to highlighting code is it’s one less task my brain has to do, freeing it up to think about the structure of the code in writing and the bigger picture.
Searching your code for that our of place ‘ is no benefit to anyone.
We use all sorts of typographical conventions to draw attention to the things we want emphasis drawn to or to encode some notion. In many novels, in English at least, a character's thoughts are italicized rather than quoted. The noir detective might be found at his desk thinking, I knew I'd seen her before, but no name came to mind. In textbooks you have a mix of bold and italics used to identify specific kind of content. Bold for new keywords students of the book should keep in mind, usually adjacent to a definition. Italics might indicate a name assigned to something: Using the pumping lemma we can...
Perhaps in our code editors we've overdone highlighting, or coloring could be a poor (certainly for some colorblind readers) method of highlighting, but syntax highlighting itself can make a great deal of sense.
It's worth considering that in the examples from prose, we usually don't draw attention to syntax, but to semantics. What does the thing with different typography mean, why is it given that special formatting or why is it surrounded by special brackets, dashes, or quotes. We don't highlight (as in the example in the article) nouns one way, verbs another, adjectives a third, and adverbs a fourth. Or verbs different ways depending on the tense or number. We highlight individual words in some manner to bring attention to them, or groups of words to indicate their logical separation in some sense from their surroundings.
[0]: https://philpapers.org/archive/DAVCAM-8.pdf