Syntax Highlighting Off(robertmelton.com)
robertmelton.com
Syntax Highlighting Off
https://www.robertmelton.com/2016/02/24/syntax-highlighting-off/
35 comments
One of the most important benefits of syntax highlighting that no one in this thread seems to be discussing is the highlighting of syntax errors. That is the number one benefit of syntax highlighting for me. It immediately shows me where there's a problem in my code (like if I haven't closed parenthesis or quotes) and keeps me focused on "completing the thought", as it were.
This is also a reason that I don't like using editor features that automatically close parenthesis or quotes when you type the opening pair. That may make the expression syntactically correct, but semantically incomplete and the burden will be on me to notice, since syntax highlighting won't help me then.
This is also a reason that I don't like using editor features that automatically close parenthesis or quotes when you type the opening pair. That may make the expression syntactically correct, but semantically incomplete and the burden will be on me to notice, since syntax highlighting won't help me then.
The author does mention that, though, when he's talking about the pros and cons in the very beginning of the article:
> What do I miss? Syntax highlighting hinting that I made a dumb typo (importance is directly proportional to compile time or speed of running syntastic).
> What do I miss? Syntax highlighting hinting that I made a dumb typo (importance is directly proportional to compile time or speed of running syntastic).
Highlighting of errors is, for me, something distinct; a background parse / compile process that reports line numbers is sufficient. It doesn't need deep integration with the editor. A keyboard shortcut to go to the next error and you're pretty much all set.
I'm also not a big fan of overly eager syntax checking because I tend to compose abstractions on the fly, leaving a statement incomplete while I flesh out a dependency, or vice versa. Syntax aware indenting usually breaks badly in this situation - I generally prefer dumb indenting, with an opt-in block or file format option for where I want to fix code over a large area. I've had big fights with Emacs over this; it almost always does the wrong thing by default, whether it's indent location, continuation indent, mixing tabs and spaces in the indent, etc. About half my .emacs is replacement indentation functionality and configuration per mode.
I also don't like auto-completing parentheses, because it puts text ahead of the cursor on the current line. That's a PITA because the editor almost invariably doesn't know when I want to complete the expression or how. Eclipse is the worst at this (it's actually not possible to turn off in a sane way). It interprets RET as completing the expression when I want a line break inside the parens, and I'm constantly having to go back and forth to work around its mistakes.
I'm also not a big fan of overly eager syntax checking because I tend to compose abstractions on the fly, leaving a statement incomplete while I flesh out a dependency, or vice versa. Syntax aware indenting usually breaks badly in this situation - I generally prefer dumb indenting, with an opt-in block or file format option for where I want to fix code over a large area. I've had big fights with Emacs over this; it almost always does the wrong thing by default, whether it's indent location, continuation indent, mixing tabs and spaces in the indent, etc. About half my .emacs is replacement indentation functionality and configuration per mode.
I also don't like auto-completing parentheses, because it puts text ahead of the cursor on the current line. That's a PITA because the editor almost invariably doesn't know when I want to complete the expression or how. Eclipse is the worst at this (it's actually not possible to turn off in a sane way). It interprets RET as completing the expression when I want a line break inside the parens, and I'm constantly having to go back and forth to work around its mistakes.
Autocompleting is by far my biggest pet peeve in modern IDEs. With default settings in Jupyter, for example, typing """ immediately creates another """. Another great one is when autocomplete tries to be vindictively clever and often deletes your open parentheses if you delete its closed parenthesis. Complete concentration killer.
> It immediately shows me where there's a problem in my code (like if I haven't closed parenthesis or quotes) and keeps me focused on "completing the thought", as it were.
Funny, because I dislike having syntax errors highlighted for the exact same reason. If I'm typing new code, I like to keep my thoughts on the reasoning behind what I'm typing, and leave it until later to "clean up" the code and get it syntactically correct. Having big red highlights around code that I haven't finished writing yet is a huge distraction... the editor seems to be beckoning to me: "Stop typing and close that paren! Why are you still typing! It's not corrreeeeect yet!!!". And usually it's enough distraction to cut off a good train of thought.
It gets worse when the editor starts complaining about full compilation errors, like calling functions I haven't written yet. When I'm in a more "creative" part of my coding (like when I'm doing lots of brand new functionality), there's a certain ordering of what I write first and what I fill in later, and having an IDE yell at me the whole time is just tiresome.
Funny, because I dislike having syntax errors highlighted for the exact same reason. If I'm typing new code, I like to keep my thoughts on the reasoning behind what I'm typing, and leave it until later to "clean up" the code and get it syntactically correct. Having big red highlights around code that I haven't finished writing yet is a huge distraction... the editor seems to be beckoning to me: "Stop typing and close that paren! Why are you still typing! It's not corrreeeeect yet!!!". And usually it's enough distraction to cut off a good train of thought.
It gets worse when the editor starts complaining about full compilation errors, like calling functions I haven't written yet. When I'm in a more "creative" part of my coding (like when I'm doing lots of brand new functionality), there's a certain ordering of what I write first and what I fill in later, and having an IDE yell at me the whole time is just tiresome.
Alongside the errors which I agree with and mentioned elsewhere one of the things I really like about intellij (sure others do it) is you can highlight the variable under the cursor in different colors (for read/write), I have mine set to dark red for writes and green for reads, That really helps as you jump around code as you can stick it on a method and it highlights all calls to that method in the code.
I wasn't aware there was anything more to syntax highlighting than what you are calling "lexical highlighting" - what I think of as "syntax highlighting" consists of coloring comments, string literals, and reserved words differently than identifiers or punctuation marks. So, I gather that there must be some editors which use more complicated schemes; can you point me at an example?
this, for me, is a frustrating aspect of programming from a user's perspective
when someone builds something they often 'hard code' their own specific interests into the thing
so let's say i am like you, and only want the comments highlighted.. if the highlighter i am using fails to allow me to alter it from the user side of things i'll have to dive into the source
if it is closed then i have to take the time to build my own wheel
if it is is open, but after investigation i find the functionality is hardcoded, piecemeal, and highly specific then i have to take the time to build my own wheel
this is an overly simplistic example of what i am trying to illuminate but from a user's perspective there is a huge difference between these equations:
when someone builds something they often 'hard code' their own specific interests into the thing
so let's say i am like you, and only want the comments highlighted.. if the highlighter i am using fails to allow me to alter it from the user side of things i'll have to dive into the source
if it is closed then i have to take the time to build my own wheel
if it is is open, but after investigation i find the functionality is hardcoded, piecemeal, and highly specific then i have to take the time to build my own wheel
this is an overly simplistic example of what i am trying to illuminate but from a user's perspective there is a huge difference between these equations:
print(51)
n=3*17
print(n)
a=3
e=17
print(a*e)
a=sys.argv[1]
e=sys.argv[2]
print(a*e)
"One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it."
How about an analogy from cooking, too?
"It's easy to spot all the verbs, but why on Earth would you want to do that? "
Well, exactly! Makes it obvious how stupid your argument is, huh?!
I'm pretty sure the people who choose syntax colouring know what they're doing, just like the ones who don't use it. One of those choice things.
How about an analogy from cooking, too?
"It's easy to spot all the verbs, but why on Earth would you want to do that? "
Well, exactly! Makes it obvious how stupid your argument is, huh?!
I'm pretty sure the people who choose syntax colouring know what they're doing, just like the ones who don't use it. One of those choice things.
... sorry but syntax highlighting on spoken languages for parts of speech would be CRAZY useful when learning to read that language.
"Reading code is simply more straightforward, smoother and less jumpy. I get the overarching context faster and with less hassle."
This makes me think the author might be one of those people who can not superficially scan text very efficiently and resort to.. well, just reading it, word by word. (Is there a term for this phenomenon?)
This makes me think the author might be one of those people who can not superficially scan text very efficiently and resort to.. well, just reading it, word by word. (Is there a term for this phenomenon?)
Having highlight off forces him to focus on the code really hard, which may make it seem like it is helping him to understand the code. And looking at his code examples, he really needs it, so good for him.
Yeah, syntax highlighting definitely makes things easier to scan and quickly process a file in my head.
It also helps with instantly seeing if you are missing a "/' (or used the wrong one to terminate a string variable), as the rest of the line/file has the wrong colours.
It also helps with instantly seeing if you are missing a "/' (or used the wrong one to terminate a string variable), as the rest of the line/file has the wrong colours.
Agreed, it also depends on what you're trying to do. If you have time to read and comprehend each and every line of code then that's obviously ideal, but time is the most precious resource we have. I find properly implemented syntax highlighting provides a "visual outline" of the code which I can use like a table of contents or index. This allows me to save time and focus for the segments of code that require my full attention. Sure it makes things more "jumpy" and sometimes I have to backtrack to get context, but I find it makes the overall process much more time-efficient.
I'd also point out turning off highlighting may produce a false perception if the color scheme you're switching from is mediocre or worse (as most of them are in my experience). To a starving man McDonalds tastes like heaven. Properly implemented syntax highlighting shouldn't be distracting in the first place. If you're using syntax highlighting and have trouble reading code line-by-line then that's just a sign you need a better color scheme IMO. I switched from some random theme I found online to solarized-dark a couple of years ago and found it made the reading experience much smoother.
At any rate I'm glad he's found something that makes his programming more productive and enjoyable, but I would avoid categorizing it as objectively better, as the author tries to do.
I'd also point out turning off highlighting may produce a false perception if the color scheme you're switching from is mediocre or worse (as most of them are in my experience). To a starving man McDonalds tastes like heaven. Properly implemented syntax highlighting shouldn't be distracting in the first place. If you're using syntax highlighting and have trouble reading code line-by-line then that's just a sign you need a better color scheme IMO. I switched from some random theme I found online to solarized-dark a couple of years ago and found it made the reading experience much smoother.
At any rate I'm glad he's found something that makes his programming more productive and enjoyable, but I would avoid categorizing it as objectively better, as the author tries to do.
I have several modes of reading code, from scanning very fast to find a section (highlighting helps a lot), to reading at medium speed for obtaining overall gist (highlighting good?), to slowly reading for accuracy (highlighting not needed).
It would be a pain to turn highlighting on/off since I switch modes rapidly and often. But I can image a mode where it changes highlighting based on scrolling speed. It would be easy fade the CSS colors to/from B/W on the fly.
It would be a pain to turn highlighting on/off since I switch modes rapidly and often. But I can image a mode where it changes highlighting based on scrolling speed. It would be easy fade the CSS colors to/from B/W on the fly.
Next step: programming using ed.
But jokes aside, use whatever environment you like best. For me syntax highlighting is extremely useful. Knowing whether some strings of characters is a type or a variable, or a class type or a basic type makes programming just that much easier. It also helps catching simple typos if something doesn't have the color you'd expect.
But jokes aside, use whatever environment you like best. For me syntax highlighting is extremely useful. Knowing whether some strings of characters is a type or a variable, or a class type or a basic type makes programming just that much easier. It also helps catching simple typos if something doesn't have the color you'd expect.
A high number of Unix programmers (Ken Thompson, Brian Kernighan, Doug McIlroy, Tom Duff & Bjarne Stroustrup) used sam at Bell Labs, which is known as "ed on steroids, lots of steroids".
http://sam.cat-v.org/
http://sam.cat-v.org/
From an interview with Peter Salus [1]:
By the way, 'em' stands for 'editor for mortals' - I
christened it that after Ken Thompson visited our lab at
QMC while I was developing it and said something like:
"yeah, I've seen editors like that, but I don't feel a need
for them, I don't want to see the state of the file when
I'm editing".
Ed is fun. I admit that it's mere geekery to prefer it over something feasible, but it's worth it when you spend an afternoon just playing with it. Also I guess it'd be nice exercise for vi users. But some syntax highlighting is really useful nearly universally.
A step up from ed but a step below vim is nvi.
I've always preferred nvi over vim because:
1) there's no lag when I scroll up or down through a file line-by-line,
2) it shows a list of matching files by default when using tab completion in command mode (same as bash), vs picking the first matching filename, and
3) it uses fewer resources when you screw up (http://galexander.org/vim_sucks.html)
I used to think that the lack of syntax highlighting was its biggest weakness, but now that's apparently a virtue :-) .
I've always preferred nvi over vim because:
1) there's no lag when I scroll up or down through a file line-by-line,
2) it shows a list of matching files by default when using tab completion in command mode (same as bash), vs picking the first matching filename, and
3) it uses fewer resources when you screw up (http://galexander.org/vim_sucks.html)
I used to think that the lack of syntax highlighting was its biggest weakness, but now that's apparently a virtue :-) .
Re 2)
I just tried the benchmark from the article that you linked ("1000000aaeou<ESC>"), and it really did not complete in a useful timeframe. However, when I insert the text once, yank it, then paste it with repeat ("iaeou<ESC>^y4l1000000p"), the operation completes instantly, and I can still browse the file without any slowdown. Undo/redo across this operation seems to take some seconds, though.
set wildmode=list:longest
I just tried the benchmark from the article that you linked ("1000000aaeou<ESC>"), and it really did not complete in a useful timeframe. However, when I insert the text once, yank it, then paste it with repeat ("iaeou<ESC>^y4l1000000p"), the operation completes instantly, and I can still browse the file without any slowdown. Undo/redo across this operation seems to take some seconds, though.
Thanks for the list hint!
I find syntax highlighting is brilliant for focusing on small elements in code. Switching it off is useful for looking at the overall structure of a closure.
Well, not ed, but refactoring Haskell code with sed incredibly nice.
Many syntax highlight themes seem to hide comments in code by decreasing their contrast. I'm strongly against that so for me the author lost credibility when I saw that's more or less only what his theme do.
Comments lie, frequently. The only time I need to look a comments is when someone has done a poor job of naming things. The comments may explain intent, but they do not explain what it's doing.
Never question someone's credibility because their preference differs from yours. It'll make people question your credibility.
Never question someone's credibility because their preference differs from yours. It'll make people question your credibility.
Why does the author having different preferences have anything to do with his credibility?
That does depend where you sit on the spectrum between wanting ubiquitous commenting and believing that comments are themselves a smell.
I've wondered about that too. Low contrast / dimmed comments are basically saying "I spent time writing this, but it's not important, disregard". I'm sure it's part of the reason why comments are often not updated - they just don't stand out / draw attention to themselves.
Of course, legible code is more important in most cases.
Of course, legible code is more important in most cases.
> Low contrast / dimmed comments are basically saying "I spent time writing this, but it's not important, disregard".
One could make the opposite argument that comments are the important part and you only need to read code when diving in. This would be sort of a literate coding. I'm torn between making comments dimmer or brighter.
One could make the opposite argument that comments are the important part and you only need to read code when diving in. This would be sort of a literate coding. I'm torn between making comments dimmer or brighter.
Many color schemes take the most important parts and fade them out: comments!
In Haskell I have different colors for the comments, keywords, and literals. That's it. Anything more is not helpful.
It's baffling to me to look at source on Github and see a screen full of comments, greyed out.
In Haskell I have different colors for the comments, keywords, and literals. That's it. Anything more is not helpful.
It's baffling to me to look at source on Github and see a screen full of comments, greyed out.
I hate when comments are highlighted. Makes it difficult to read the code as they distract me.
The code is what is hard to read, comments are easy to read. I want help focusing on the code, I don't mind if the highlight structure doesn't help me read the comments as they are more than easy to read already.
The code is what is hard to read, comments are easy to read. I want help focusing on the code, I don't mind if the highlight structure doesn't help me read the comments as they are more than easy to read already.
Comments are like footnotes in a book: great for adding context to the main text, but they work really well when shoved off to the side somewhere, easily accessible to those who want them, easily ignored by those just into the main text (e.g. Author). Unfortunately, code typography is so horrible in our field that we lack the ability to use the bottom page margin or a side bar for this purpose, so we hack it up with what's easy: syntax highlighting.
Comments also lie.
At best, they are a statement that, at the time they were last edited, the author believed their stated facts were true, or might become so, plenty are aspirational, "this is what this function or change to it, which I've not yet written, will do".
He might have been wrong, or the code might have changed without updating the comment, the actual running code is the only truth.
At best, they are a statement that, at the time they were last edited, the author believed their stated facts were true, or might become so, plenty are aspirational, "this is what this function or change to it, which I've not yet written, will do".
He might have been wrong, or the code might have changed without updating the comment, the actual running code is the only truth.
I find that comments at the top of functions are helpful when implementing an algorithm found in reference material, especially if they have a citation. At least that way you can check that the function appears to do what the reference material specifies.
But generally commit messages, descriptive symbols, simple logic, short functions, and unit tests are better.
But generally commit messages, descriptive symbols, simple logic, short functions, and unit tests are better.
To some degree I agree, but even if they don't lie they can still get in the way of code reading given the current sad state of code typography. If comments were handled better, I bet they would be updated more regularly with code changes since it would be more of an eye sore if they weren't.
I started programming a long time ago, without any syntax highlighting at all, and the first time I tried it I found that all the different colours were more distracting than without, so count me as another for whom it's always remained off.
On the subject of unusual programming preferences, perhaps antialiasing off would be the next one the author could try. For me completely off is most comfortable, regular grayscale antialiasing is just bearable, and subpixel (like what's shown in his screenshots) just makes me feel dizzy after a short time.
On the subject of unusual programming preferences, perhaps antialiasing off would be the next one the author could try. For me completely off is most comfortable, regular grayscale antialiasing is just bearable, and subpixel (like what's shown in his screenshots) just makes me feel dizzy after a short time.
[deleted]
I've always wanted to try this.
I started programming in 7th grade by randomly typing commands into my TI-83 during algebra class. I had no syntax highlighting, auto-complete, or even a choice of font, but I would sit there for _hours_ meticulously making lines jump around the screen.
Now I get stressed out when my color scheme isn't perfect.
I started programming in 7th grade by randomly typing commands into my TI-83 during algebra class. I had no syntax highlighting, auto-complete, or even a choice of font, but I would sit there for _hours_ meticulously making lines jump around the screen.
Now I get stressed out when my color scheme isn't perfect.
I use syntax highlighting, but I prefer it to be quite minimalist. I use bold for keywords and different colors for string literals and comments. Also I use underscore for object fields. Modern IDEs usually configured with a lot of visual noise and it might make it harder to read, but probably it depends on person.
Syntax highlighting can help structuring your source code when done well and tastefully - coloring your source in all bright colors of the rainbow rather achieves the opposite effect.
Personally I am working with a white background, so I try to keep the syntax colors all very dark, so while the different colors can be seen, they should not distract from reading. The correct amount of highlighting very much depends from the language at hand, but it can be very helpful in separating elements, just as an example take this function parameter list:
func foo(name, family string, age, size int) {
The correct reading of this parameter list entirely depends on the placement of the commas and the knowledge that "string" and "int" are parameter types - highlighting the type elements can help a lot.
With the availability of high-dpi displays, perhaps colors should be replaced with more traditional ways of markup as used in book-printing, replace coloring with different typesets and fonts.
Personally I am working with a white background, so I try to keep the syntax colors all very dark, so while the different colors can be seen, they should not distract from reading. The correct amount of highlighting very much depends from the language at hand, but it can be very helpful in separating elements, just as an example take this function parameter list:
func foo(name, family string, age, size int) {
The correct reading of this parameter list entirely depends on the placement of the commas and the knowledge that "string" and "int" are parameter types - highlighting the type elements can help a lot.
With the availability of high-dpi displays, perhaps colors should be replaced with more traditional ways of markup as used in book-printing, replace coloring with different typesets and fonts.
> coloring your source in all bright colors of the rainbow rather achieves [badness]
Low-hanging fruit is the braindead R/G/B/Cyan/Magenta/Yellow used by some terminals in response to ANSI escape codes: https://sdkmvx.files.wordpress.com/2008/08/ansi-colors.png
In my mind, there's three types of colouring: None, Designed-By-Human, and the aforementioned Eye-Searing-255 (which should really be killed off or at least not be the default for anything used seriously). It's disgusting to open source code using vi or similar and have it presented in Eye-Searing-255.
Low-hanging fruit is the braindead R/G/B/Cyan/Magenta/Yellow used by some terminals in response to ANSI escape codes: https://sdkmvx.files.wordpress.com/2008/08/ansi-colors.png
In my mind, there's three types of colouring: None, Designed-By-Human, and the aforementioned Eye-Searing-255 (which should really be killed off or at least not be the default for anything used seriously). It's disgusting to open source code using vi or similar and have it presented in Eye-Searing-255.
> Eye-Searing-255
Lol....this. If your primary workstation OS is Windows then I recommend grabbing a copy of MobaXTerm. It has the ability to override and tame the "Eye-Searing-255" beast with its own themes (Solarized Dark and Light, Pastels etc). No more "oh-my-god-my-eyes" when you open up "ooby-doofer.pl" in vim.
Lol....this. If your primary workstation OS is Windows then I recommend grabbing a copy of MobaXTerm. It has the ability to override and tame the "Eye-Searing-255" beast with its own themes (Solarized Dark and Light, Pastels etc). No more "oh-my-god-my-eyes" when you open up "ooby-doofer.pl" in vim.
I've found an agreeable middle ground, which is to keep syntax highlighting on but to use a monochrome theme, where different types of tokens (like you mention) are distinguished by contrast instead of color. However, I don't personally favor pure blacks or whites (just ask any master printer).
I do make exceptions. For example, I color my cursor, as well as highlight matching parens if the cursor is on one of the pair (changing just the foreground color of the paren, not inverting it). The only color I use is red.
I don't make any objective claims that this is better, my aim is to make something "done well and tasteful", as you say.
I do make exceptions. For example, I color my cursor, as well as highlight matching parens if the cursor is on one of the pair (changing just the foreground color of the paren, not inverting it). The only color I use is red.
I don't make any objective claims that this is better, my aim is to make something "done well and tasteful", as you say.
One of my criteria for choosing a theme for source highlighting is that it not make keywords both bright and bold at the same time, which makes code harder to read and to scan. A startling number of themes do this.
Judicious, typographically aware use of bold and italic or oblique in source highlighting can be a wonderful thing.
Judicious, typographically aware use of bold and italic or oblique in source highlighting can be a wonderful thing.
[deleted]
I've had syntax highlighting enabled in Vim for many years without really thinking about it. I just recently started to learn a new programming language (Go) and that got me thinking about the effects of syntax highlighting. I felt that colours would distract me from efficiently learning the syntax of the language so I turned it off for a while, now I'm never going back.
(I really do like having another color on just comments though, code > comments. Separating them makes a big difference when reading source code for me.)
Ended up having to create a Vim color scheme to get what I wanted: https://github.com/ggustafsson/Static-Color-Scheme
(I really do like having another color on just comments though, code > comments. Separating them makes a big difference when reading source code for me.)
Ended up having to create a Vim color scheme to get what I wanted: https://github.com/ggustafsson/Static-Color-Scheme
For me, it really helps to have code and comments the same colour. That way I give comments the attention they deserve, and I can resist the temptation to comment out code.
What I've once read is that the advantages for syntax highlighting are biggest for beginners (in general or in that programming language). This seems logical when looking at what syntax highlighting does: colouring differently according to the token type. Beginners might have more problems finding the borders of what belongs together and what kind of token something is.
If we compare this with classical text, we won't have any typographic help for the inner structures of sentences, maybe simply because colouring different types of words differently was quite hard. Typography there is used for the outer structure. Mostly vertical space is used to separate paragraphs. This is also used in programming. However making headlines bigger and use a different type isn't used in programming. Programming uses indentation instead. It is pretty obvious that it's this way because of the limitations of the medium in the beginning. Also it's not as easy as classifying tokens.
If we compare this with classical text, we won't have any typographic help for the inner structures of sentences, maybe simply because colouring different types of words differently was quite hard. Typography there is used for the outer structure. Mostly vertical space is used to separate paragraphs. This is also used in programming. However making headlines bigger and use a different type isn't used in programming. Programming uses indentation instead. It is pretty obvious that it's this way because of the limitations of the medium in the beginning. Also it's not as easy as classifying tokens.
It can also help when jumping around between many different languages, especially when they are similar.
Interestingly enough, the author of the article notes that it has become easier for him to jump around different languages.
I don't understand the reasoning behind this. What possible benefit could you get from turning off all syntax highlighting?
It's useful to distinguish between language keywords and user specified names. Being able to visually ignore one of them, while focusing on the other, is a tremendous benefit. It cuts down the number of things you need to hold in your head at once, by half.
It's useful to distinguish between local variables and instance variables. It helps to better understand the dependencies that exist between a method and other methods/state.
It's useful to distinguish between mutable variables, and constants. It tells you at a glance how something is being used, and the pitfalls you need to watch out for.
Turning off all syntax highlighting destroys all of the benefits above, and I can't think of any notable benefit you would get out of it.
I guarantee you, whatever "upside" you think you're feeling right now, it's simply the novelty effect. This is a very common phenomenon in AB testing. Often times, you see an initial improvement, simply because users respond positively to the initial novelty of something being different. I guarantee you, if you continue to work without syntax highlighting for 6 months, and then turn it back on for a few weeks, you'll realize how much you actually love it.
It's useful to distinguish between language keywords and user specified names. Being able to visually ignore one of them, while focusing on the other, is a tremendous benefit. It cuts down the number of things you need to hold in your head at once, by half.
It's useful to distinguish between local variables and instance variables. It helps to better understand the dependencies that exist between a method and other methods/state.
It's useful to distinguish between mutable variables, and constants. It tells you at a glance how something is being used, and the pitfalls you need to watch out for.
Turning off all syntax highlighting destroys all of the benefits above, and I can't think of any notable benefit you would get out of it.
I guarantee you, whatever "upside" you think you're feeling right now, it's simply the novelty effect. This is a very common phenomenon in AB testing. Often times, you see an initial improvement, simply because users respond positively to the initial novelty of something being different. I guarantee you, if you continue to work without syntax highlighting for 6 months, and then turn it back on for a few weeks, you'll realize how much you actually love it.
>I don't understand the reasoning behind this. What possible benefit could you get from turning off all syntax highlighting?
He explained his reasoning (and theories why it would work) in enough detail. You might disagree, but I can't see how you can't understand it.
>It's useful to distinguish between language keywords and user specified names. Being able to visually ignore one of them, while focusing on the other, is a tremendous benefit. It cuts down the number of things you need to hold in your head at once, by half.
That's the conventional thinking. The whole point of TFA is that it's not useful -- rather it's distracting, making eyes automatically focus in such distinctions while losing the bigger picture.
Plus, just because you've colored "language keywords and user specified names" doesn't mean it's now easier to "visually ignore" one of them while focused on the other, it can mean the exact opposite: the extra color distraction makes you jump from one to the other -- unless you put extra conscious effort.
He explained his reasoning (and theories why it would work) in enough detail. You might disagree, but I can't see how you can't understand it.
>It's useful to distinguish between language keywords and user specified names. Being able to visually ignore one of them, while focusing on the other, is a tremendous benefit. It cuts down the number of things you need to hold in your head at once, by half.
That's the conventional thinking. The whole point of TFA is that it's not useful -- rather it's distracting, making eyes automatically focus in such distinctions while losing the bigger picture.
Plus, just because you've colored "language keywords and user specified names" doesn't mean it's now easier to "visually ignore" one of them while focused on the other, it can mean the exact opposite: the extra color distraction makes you jump from one to the other -- unless you put extra conscious effort.
Yes, I read his reasoning, but I still can't make sense of it. The most common theme seems to be that having more colors is "distracting". I mean yes, having more colors gives your eyes more things to process... the same way that 7 letter variable names creates more work for your eyes compared to 2 letter variable names. But if someone told me that they avoid naming their variables using complete words because it's too distracting, and only used 2 letter symbols, I wouldn't understand that either.
From a physics/math perspective, yes, I get that "more" implies more entropy. Having 4 colors on your screen is more entropy compared to 2 colors. Having 7 letter names is more entropy than having 2 letter names. But if that additional entropy is used to convey clear, unambiguous and useful information, it actually makes the overall message simpler. The same way that long/descriptive variable names make reading code simpler compared to random 2 letter symbols.
On more reflection, the one reasoning I can somewhat understand, is the idea of handicapping yourself. If you force yourself to type with one hand behind your back, it gives your brain additional incentive to find concise solutions. In theory, I guess I understand this line of reasoning, but in practice, I'll still continue typing with both hands, thank you very much.
Anyway, just thinking aloud here. When I come across something I don't understand, I try my best to understand what the other side might be thinking. Not trying to attack anyone... to each his own. Best wishes.
From a physics/math perspective, yes, I get that "more" implies more entropy. Having 4 colors on your screen is more entropy compared to 2 colors. Having 7 letter names is more entropy than having 2 letter names. But if that additional entropy is used to convey clear, unambiguous and useful information, it actually makes the overall message simpler. The same way that long/descriptive variable names make reading code simpler compared to random 2 letter symbols.
On more reflection, the one reasoning I can somewhat understand, is the idea of handicapping yourself. If you force yourself to type with one hand behind your back, it gives your brain additional incentive to find concise solutions. In theory, I guess I understand this line of reasoning, but in practice, I'll still continue typing with both hands, thank you very much.
Anyway, just thinking aloud here. When I come across something I don't understand, I try my best to understand what the other side might be thinking. Not trying to attack anyone... to each his own. Best wishes.
I found the Alice in Wonderland image at http://www.linusakesson.net/programming/syntaxhighlighting/ particularly compelling, in support of the argument that highlighting may emphasize syntax at the cost of obscuring semantics.
I've not found that Alice analogy colorizing the "verbs" convincing.
With human language like English, we learn it and use it without the formal grammar++. A 5-year old child can speak to her mother ("I want some candy!") without conscious knowledge of "verbs" or "nouns". A formal grammar for categorization is what we layer on top of language for analysis in school. Two people can communicate and understand each other without any exposure to any grammar lessons. So yes, colorizing verbs looks superfluous and noisy.[2]
On the other hand, computer programming syntax starts with grammar. You learn that certain specific tokens are "data types" and other tokens are "literals", etc, etc. And that grammar categorization in programming languages never goes away as you're typing out new code. (Otherwise, you'd get a compiler error or unintended behavior because x="3"+"5" with quotes ("35") means something different from x=3+5 without quotes (8).) This is why so many programmers find color highlighting helpful even if they've been programming that language for 10+ years. Sure we want to focus on higher cognitive purpose of "semantics" but the grammar is deeply intertwined with reconstructing what the semantics is.
A closer analogy of color highlighting in a different realm would be different colors in TCPIP traces such as "red" highlighting external ip addresses. This can be helpful for forensics of malware phoning home.
Or in financials dashboards where uptrends are "green" and downtrends are "red".
The same reasons that colors help the malware analyst or stock trader quickly parse data at a glance is also how it helps programmers.
++ (at least not consciously that a 5-year old would be self-aware of it. A theory of innate universal grammar in the brain by Chomsky isn't what I'm talking about.)
[2] except for rare examples of using annotation or coloring of verbs to help parse sentences like this: https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
With human language like English, we learn it and use it without the formal grammar++. A 5-year old child can speak to her mother ("I want some candy!") without conscious knowledge of "verbs" or "nouns". A formal grammar for categorization is what we layer on top of language for analysis in school. Two people can communicate and understand each other without any exposure to any grammar lessons. So yes, colorizing verbs looks superfluous and noisy.[2]
On the other hand, computer programming syntax starts with grammar. You learn that certain specific tokens are "data types" and other tokens are "literals", etc, etc. And that grammar categorization in programming languages never goes away as you're typing out new code. (Otherwise, you'd get a compiler error or unintended behavior because x="3"+"5" with quotes ("35") means something different from x=3+5 without quotes (8).) This is why so many programmers find color highlighting helpful even if they've been programming that language for 10+ years. Sure we want to focus on higher cognitive purpose of "semantics" but the grammar is deeply intertwined with reconstructing what the semantics is.
A closer analogy of color highlighting in a different realm would be different colors in TCPIP traces such as "red" highlighting external ip addresses. This can be helpful for forensics of malware phoning home.
Or in financials dashboards where uptrends are "green" and downtrends are "red".
The same reasons that colors help the malware analyst or stock trader quickly parse data at a glance is also how it helps programmers.
++ (at least not consciously that a 5-year old would be self-aware of it. A theory of innate universal grammar in the brain by Chomsky isn't what I'm talking about.)
[2] except for rare examples of using annotation or coloring of verbs to help parse sentences like this: https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
The main problem is garish colors. If colors were a bit more subdued, the text would've been just as easy to read. That applies to code as well: bright red letters on black background are extremely distracting, dark purple letters on white background are not at all distracting.
As the author himself points out (though after making an argument that implies the opposite), code is not prose. Prose has its own base elements, such as phrases and titles, and it does use visual cues to point them out, such as capitalization and larger fonts.
I have been without syntax highlighting for two years now, and I don't miss it. Have tested using it again, but feelt it distracting. For me the main advantage is that without the colours it is easier to see when a certain part of the code is 'ugly'. With syntax highlighting on, everything is a soup of colors anyway. Also, when highlighting makes comments light gray and almost invisible, it is easy to leave a commented-out mess of old code around. When comments are given the same emphasis as real code I care more about them, and make them tidy too. I don't find the extra information provided by colours useful. I'd rather spend five seconds going back to the declaration of the variable (in my editor, it is a simple right click to jump between usages of a string), which will also remind me of its type and the context it was introduced, since if I am unsure about its scope, chances are there are more aspects of the item which I am unsure of.
It is an hipster thing, coding without syntax highlighting, no completion, only CLI and the original Vi.
or it is a reaction to too much syntax highlighting, overloaded toolbars, endless contextual menus and general sophistication that penetrated every pore of software development.
as one of the comments here quoted: "syntax highlighting, while aesthetically seductive, moves focus from content to form". Sums up the state of art in IT.
as one of the comments here quoted: "syntax highlighting, while aesthetically seductive, moves focus from content to form". Sums up the state of art in IT.
I have been using syntax highlighting since Turbo Pascal 7.0, it has never been a problem.
Some people are definitely in the camp against syntax highlighting.
Some examples:
1. Linux Akesson (LFT) wrote an article quite some time ago about it: http://www.linusakesson.net/programming/syntaxhighlighting/
"A case against syntax highlighting:
Do you rely on syntax highlighting when developing software? If so, you may be shooting yourself in the foot. In this post, I will argue that syntax highlighting, while aesthetically seductive, moves focus from content to form, and discourages those who look at the code from trying to understand it."
2. The Acme text editor does not support syntax highlighting and probably never will. Prominent contributors to golang use this editor.
On my own, I started to program without syntax highlighting, then used it and now I use a much weaker one. I like to be able to track individual variables by color as a form of semantic highlighting and to bring up comments rather than dimming them like it's often done.
Some examples:
1. Linux Akesson (LFT) wrote an article quite some time ago about it: http://www.linusakesson.net/programming/syntaxhighlighting/
"A case against syntax highlighting:
Do you rely on syntax highlighting when developing software? If so, you may be shooting yourself in the foot. In this post, I will argue that syntax highlighting, while aesthetically seductive, moves focus from content to form, and discourages those who look at the code from trying to understand it."
2. The Acme text editor does not support syntax highlighting and probably never will. Prominent contributors to golang use this editor.
On my own, I started to program without syntax highlighting, then used it and now I use a much weaker one. I like to be able to track individual variables by color as a form of semantic highlighting and to bring up comments rather than dimming them like it's often done.
This post misses, for me, the greatest benefit of programming without syntax highlighting enabled. I went through a period of doing it for 5 years or so and the biggest effect was ultimately on how I wrote code, not how I read it.
Without syntax highlighting I gradually became more focused on the legibility of what I was writing, because none of the visual cues were there when I read stuff back. Function length, module size, naming and vertical whitespace were are all things that I began to think more deeply about.
I turned syntax highlighting back on a few years ago because I was getting so many complaints from co-workers when pairing on stuff at my machine. But I definitely think the experience made me a more considerate, better programmer and I'm glad I did it.
Without syntax highlighting I gradually became more focused on the legibility of what I was writing, because none of the visual cues were there when I read stuff back. Function length, module size, naming and vertical whitespace were are all things that I began to think more deeply about.
I turned syntax highlighting back on a few years ago because I was getting so many complaints from co-workers when pairing on stuff at my machine. But I definitely think the experience made me a more considerate, better programmer and I'm glad I did it.
I'm glad you had a positive experience, but I'd like to point out that thinking about legibility, whitespace, naming etc should be done regardless of highlighting.
I don't blame you, IMO it's one of the major issues with computer science education. Even basic principles of clean code are often neglected or never taught, in large part due to the lack of professional experience in academic circles. This leaves aspiring developers to figure it out on their own, as you did through turning off highlighting. I'm glad you did, but there are better ways to learn the same concepts IMO.
I don't blame you, IMO it's one of the major issues with computer science education. Even basic principles of clean code are often neglected or never taught, in large part due to the lack of professional experience in academic circles. This leaves aspiring developers to figure it out on their own, as you did through turning off highlighting. I'm glad you did, but there are better ways to learn the same concepts IMO.
>Even basic principles of clean code are often neglected or never taught, in large part due to the lack of professional experience in academic circles.
There's a lack of experience in professional circles too.
One of the questions I always ask during programming interviews (on either side) is "is your code clean? if so, why?". Invariably the answer is a variant along the lines of "if it passes the linter it's clean", which is stupid.
I'd like to say that's an automatic fail or automatic "don't work at this company" but it's just far too common.
There's a lack of experience in professional circles too.
One of the questions I always ask during programming interviews (on either side) is "is your code clean? if so, why?". Invariably the answer is a variant along the lines of "if it passes the linter it's clean", which is stupid.
I'd like to say that's an automatic fail or automatic "don't work at this company" but it's just far too common.
Perhaps you should use a less ambiguous term than "clean". They're giving you a correct answer, so perhaps you should ask the correct question? "Is your code readable", perhaps? "Are you proud of your code?". Something like that. No-one's going to admit their code isn't clean, regardless of how they interpret that term.
I think 'clean' can only be evaluated in context.
For instance, whenever I write code for public distribution I try to use the same layout principles and code style rules that are popular within my target audience.
Additionally, I try to present concepts in a way that will either be idiomatic to the target audience or at the very least not judged as unusual.
To give a silly hypothetical example. If I were writing code to be delivered to a company that never uses list comprehensions within Python, I'd write everything as an explicit for-in-loop.
This is less of a problem in certain languages where there's explicit global style guides and a tendency to conservatism (Python). Other communities where that's not the case, like Smalltalk, Lisp, and now Elixir, one can see varying control statements and code inheritance methodologies practiced by different groups simply because of how easy it is to implement, and that doing so isn't shunned.
For instance, whenever I write code for public distribution I try to use the same layout principles and code style rules that are popular within my target audience.
Additionally, I try to present concepts in a way that will either be idiomatic to the target audience or at the very least not judged as unusual.
To give a silly hypothetical example. If I were writing code to be delivered to a company that never uses list comprehensions within Python, I'd write everything as an explicit for-in-loop.
This is less of a problem in certain languages where there's explicit global style guides and a tendency to conservatism (Python). Other communities where that's not the case, like Smalltalk, Lisp, and now Elixir, one can see varying control statements and code inheritance methodologies practiced by different groups simply because of how easy it is to implement, and that doing so isn't shunned.
Leaving the definition of "clean" ambiguous does give you some useful information, though, because the context implied by the answer shows you something about the interviewee's priorities. Of course their code is "clean" according to whatever metric is important to them - but what's their metric? What are they focusing on as they work?
It's A correct answer but not THE correct answer. The best answer would be clean code is just beautiful and that's why I strive for it.
>They're giving you a correct answer
Is spaghetti code clean if it lints successfully?
Is spaghetti code clean if it lints successfully?
Yes. And no. Depends on the context. Microsoft and malware coders both think windows is great for the same reason; it's very popular.
>Yes. Depends on the context.
I can't think of any context where I'd consider spaghetti code clean. It's exact opposite of clean.
I can't think of any context where I'd consider spaghetti code clean. It's exact opposite of clean.
Clean...in the sense that it passes lint, unit testing, continuous integration etc. Not clean in the sense that "internet user #1209828 approves of its aesthetics", which is a metric subject to fashion, opinion etc.
This reminds me of one of my favourite peeves when reading code written by maths people:
Every variable is one or two characters long, the code barely indented, and absolutely no spaces anywhere in the code.
Given that a lot of mathematics involves computer programming these days, I find it remarkable that basic programming principles does not seem to be taught at all.
My point here is that this is not just a problem in computer science education. It seems as though every field that touches on programming fails spectacularly in this regard.
Every variable is one or two characters long, the code barely indented, and absolutely no spaces anywhere in the code.
Given that a lot of mathematics involves computer programming these days, I find it remarkable that basic programming principles does not seem to be taught at all.
My point here is that this is not just a problem in computer science education. It seems as though every field that touches on programming fails spectacularly in this regard.
That's an interesting point. However, this will only work when you're only ever reading your own source code. In Ruby code, I've seen a lot of very long expressions formatted without any spaces at all, like: (artifical example)
@posts = Post.where(author:params[:author_id].to_i).map{|p|p.comment_count}.select{|c|c>5&&c<10}
No thanks.
I started using syntax highlighting still in the MS-DOS days, and hate when I am forced to downgrade my developer experience.
But to each its own I guess.
I started using syntax highlighting still in the MS-DOS days, and hate when I am forced to downgrade my developer experience.
But to each its own I guess.
I'd like to see slightly more difficult to read fonts as an isolated experiment in this exploration. http://www.wired.com/2011/01/the-benefit-of-ugly-fonts/
I can't recall who, either Pike or Crockford said that syntax highlighting was a regression. I kinda agree that a well balanced comment code ratio, and clear system / design makes up for most editor enhancement.
I have had syntax highlighting off for a few years, but I always turn it on when looking at XML... especially poorly formatted files. It helps my eyes navigate the soup. That's where I think the value is: it helps to make up for confusing formatting.
nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax on \| endif \|<cr><C-g>
nmap <F12> :set wrap! wrap?<cr>
There's an Atom theme called Hacking the Kernel that does some minimal bolding of keywords but is otherwise monochrome. I use it at times but never thought about whether I was faster with it.
Purely eye candy here--visual enjoyment that makes code seem more interesting and fun.
Did anybody else go from needing a white background, to preferring a dark one?
(I had the zebra effect for years when trying to read light-on-dark, then one year something changed--I don't know exactly what.)
Did anybody else go from needing a white background, to preferring a dark one?
(I had the zebra effect for years when trying to read light-on-dark, then one year something changed--I don't know exactly what.)
>> Did anybody else go from needing a white background, to preferring a dark one?
A white background was never preferable to me. So dang bright.
I started on with gray on black (BASICA) and yellow on black (Turbo Pascal 2.0). Later on things like Q-BASIC used gray on blue (which I would occasionally change to green on black), and the Borland IDE's continued with a blue background, but added syntax highlighting.
When I made the move to Windows and Visual C++, back we went to white backgrounds. Yikes. Xcode does this as well by default.
A white background was never preferable to me. So dang bright.
I started on with gray on black (BASICA) and yellow on black (Turbo Pascal 2.0). Later on things like Q-BASIC used gray on blue (which I would occasionally change to green on black), and the Borland IDE's continued with a blue background, but added syntax highlighting.
When I made the move to Windows and Visual C++, back we went to white backgrounds. Yikes. Xcode does this as well by default.
Yes, I switched to dark background mode a few years back and it's made a huge difference in my coding productivity and eye strain. There's one IDE I use occasionally that sadly has no ability to theme (PowerGUI for PowerShell) and you're stuck with a white background...and zebra effects after an hour or two using it.
Syntax highlighting is a topic where EVERYONE has an opinion, so I'll give my 2 cents as well. I am using solarized light (http://ethanschoonover.com/solarized) for my coding, and am very happy with it. I like having keywords emphasised, because they convey a lot of the structure of the program. If you need to switch syntax highlighting off to see whether code is ugly or not, you might not have a very refined sense of beauty anyway. That said, I am perfectly fine with programming without syntax highlighting, I am not dependent on it to understand code. It is similar for type inference: I think it is OK if it makes your code easier to read, if you use type inference though to a point where you cannot understand / write your code without it, you are doing it wrong.
I think the usefulness of syntax highlighting is highly dependent on the amount of colors you use. For me, anything more than three separate colors is just visually distracting.
It's also nice to have low opacity comments, as many others have said.
Oh, and never bright colors. I use solarized or similar.
It's also nice to have low opacity comments, as many others have said.
Oh, and never bright colors. I use solarized or similar.
In hindsight, while comments and strings deserve syntax highlighting there's an argument that the rest is a solution looking for a problem. I'd argue that the highlighting would be better-spent giving each nested tier of parens a distinct color. Like make the first tier brown, then do ROY G BIV, and if you need more than 8 tiers I don't want to read your code.
I've found that I really appreciate my editor's (aoeui) use of blue and black foreground colors for matching up parentheses and other brackets. Keyword highlighting is less useful apart from being a cue for correct spelling.
Former neuroscientist here. Please take this article's pop science proclamations with a grain of salt.
1) "Additionally, we process words much faster than we process colors". Wrong, I'm pretty sure areas V2/V4 received information much faster than the visual word form area, especially given that it may require a saccade to take in a long word. Not sure where this claim comes from.
2) "...we instinctively jump to luminous or high contrast colors with our eyes, interrupting reading a program in a more standard way..." Half-true. There are well-known pop-out effects, but it's unlikely we read programs the way we read prose, so it's not clear it's an interruption at all.
3) "When syntax highlighting is on you also are spending cognitive energy (which is finite) on item-specific processing rather than organizational processing." No evidence offered. I could just as easily make the counter-claim, that syntax highlighting frees up the brain to more organizational processing, since there's less load necessary to figure out item-specific properties. Not necessarily wrong, but needs to be tested.
I think the biggest mistakes in the article (and perhaps what he got from talking with his friend in the cognitive sciences) are equating prose with code, and not accounting for novelty effects. I have no doubt that coloring random words in prose disrupts things, since it's novel and captures attention. But it doesn't automatically follow that people experienced with syntax highlighting experience similar effects.
It would be cool to see more actual research in this area.
1) "Additionally, we process words much faster than we process colors". Wrong, I'm pretty sure areas V2/V4 received information much faster than the visual word form area, especially given that it may require a saccade to take in a long word. Not sure where this claim comes from.
2) "...we instinctively jump to luminous or high contrast colors with our eyes, interrupting reading a program in a more standard way..." Half-true. There are well-known pop-out effects, but it's unlikely we read programs the way we read prose, so it's not clear it's an interruption at all.
3) "When syntax highlighting is on you also are spending cognitive energy (which is finite) on item-specific processing rather than organizational processing." No evidence offered. I could just as easily make the counter-claim, that syntax highlighting frees up the brain to more organizational processing, since there's less load necessary to figure out item-specific properties. Not necessarily wrong, but needs to be tested.
I think the biggest mistakes in the article (and perhaps what he got from talking with his friend in the cognitive sciences) are equating prose with code, and not accounting for novelty effects. I have no doubt that coloring random words in prose disrupts things, since it's novel and captures attention. But it doesn't automatically follow that people experienced with syntax highlighting experience similar effects.
It would be cool to see more actual research in this area.
Excellent points. What I would add is that he talks about finite cognitive energy, but nowhere in the article mentions how highlighting helps to save the very same cognitive energy.
For example, if there's a comment in the code, without highlight you would need to follow the comment and look for closing quotes. If the comment contains escaped quotes it becomes even more difficult. With highlight you immediately see where it ends.
Another example are keywords - when they are highlighted, you don't even need to read it. You glance at them and know the meaning by their shape. While without highlighting you would have to read every single one of them to understand that they are in fact keywords and not something else.
For example, if there's a comment in the code, without highlight you would need to follow the comment and look for closing quotes. If the comment contains escaped quotes it becomes even more difficult. With highlight you immediately see where it ends.
Another example are keywords - when they are highlighted, you don't even need to read it. You glance at them and know the meaning by their shape. While without highlighting you would have to read every single one of them to understand that they are in fact keywords and not something else.
let's have a version for emacs !
I went the other direction, I programmed for decades without syntax highlighting because back in 1989 I thought ANSI color directory listings were for MS-DOS weenies, so I used a monochrome terminal for everything. I finally became a software developer and adopted syntax highlighting and haven't looked back. Catching unterminated strings and mismatched do..end blocks in ruby saves an incredible amount of time where you can just fix it immediately in-editor as you are coding.
I find it amusing that now we've got hipster programmers wanting to get back to basics and reject syntax highlighting. Trust me, its not better, colors do make you more efficient.
I find it amusing that now we've got hipster programmers wanting to get back to basics and reject syntax highlighting. Trust me, its not better, colors do make you more efficient.
Typical mind fallacy.
I've tried both and am vastly more productive with it off. Other people haved tried both and are vastly more productive with it on.
I do often encourage people to try whichever one they're not currently using for a month as an experiment to see if they want to switch - calling people hipsters for performing an experiment to try and make themselves a better programmer strikes me as rather depressing.
I've tried both and am vastly more productive with it off. Other people haved tried both and are vastly more productive with it on.
I do often encourage people to try whichever one they're not currently using for a month as an experiment to see if they want to switch - calling people hipsters for performing an experiment to try and make themselves a better programmer strikes me as rather depressing.
I tried it with and without recently, I found that for languages I'm familiar with having it on or off made no difference however having flag errors on off did.
For languages I don't use much I found having it on more helpful, could I work without it of course, I grew up with computers that didn't have syntax highlighting but I'd miss it.
One side result of the experiment was that I turned down the number of colours I used, not everything needs to be a different colour.
For languages I don't use much I found having it on more helpful, could I work without it of course, I grew up with computers that didn't have syntax highlighting but I'd miss it.
One side result of the experiment was that I turned down the number of colours I used, not everything needs to be a different colour.
The only synhi I've ever not actively hated was the elvis defaults on a slackware install ten years ago, which basically bolded/italiced/faded text but didn't change the colour.
you're talking about a different aspect though. he says that you're more productive if you're writing a lot of code at one time.
you're saying that its easier to catch minor syntax errors with syntax highlighting.
this could, technically, be combined. i.e. writing code without syntax highlighting and enabling it for a quick glance to catch these errors that get obvious with the highlighting.
you're saying that its easier to catch minor syntax errors with syntax highlighting.
this could, technically, be combined. i.e. writing code without syntax highlighting and enabling it for a quick glance to catch these errors that get obvious with the highlighting.
I do something very similar (grey strings/comments, some bold/underline identifiers): http://i.imgur.com/i5j0QKT.png
I really like that colorscheme, care to share it?
Hmm not sure if this is exactly what you are looking for, but this is the relevant section in my CUSTOM-SET-FACES:
'(font-lock-builtin-face ((t (:weight bold))))
'(font-lock-comment-face ((t (:foreground "#707470"))))
'(font-lock-constant-face ((t (:underline t))))
'(font-lock-doc-face ((t (:inherit font-lock-comment-face))))
'(font-lock-function-name-face ((t (:inherit font-lock-constant-face))))
'(font-lock-keyword-face ((t (:weight bold))))
'(font-lock-preprocessor-face ((t (:underline (:color foreground-color :style wave)))))
'(font-lock-string-face ((t (:foreground "#707470"))))
'(font-lock-type-face ((t (:inherit font-lock-constant-face))))
'(font-lock-variable-name-face ((t (:inherit font-lock-constant-face))))
'(font-lock-warning-face ((t nil)))
'(fringe ((t (:background "#ffffff"))))
'(glyphless-char ((t (:slant italic))))
'(highlight ((t (:weight bold))))
'(isearch ((t (:box (:line-width 1 :color "#000000")))))
'(isearch-fail ((t (:weight bold))))
'(italic ((t (:slant italic))))
'(lazy-highlight ((t (:box (:line-width 1 :color "#d0d4d0")))))
'(link ((t (:inherit button))))
'(link-visited ((t (:inherit link :box (:line-width 1 :color "#707470" :style pressed-button)))))
'(minibuffer-prompt ((t (:weight bold))))
'(mode-line ((t (:inherit mode-line :background "gray93" :foreground "#000000" :height 110 :family "Source Sans Pro"))))
'(mode-line-emphasis ((t (:underline t))))
'(mode-line-inactive ((t (:inherit mode-line))))
'(mouse ((t (:background "#000000" :foreground "#ffffff"))))
'(region ((t (:background "#d0d4d0"))))
'(secondary-selection ((t (:background "#e9eee9"))))
'(show-paren-match ((t (:weight bold))))
'(show-paren-mismatch ((t (:underline t))))
[deleted]
Thanks. I use Jetbrains IDE's for coding where my colorschemes have a similar setup. Code, Comments, Strings, are different, and that's about it. Never got around to doing this in Vim which I still use for many tasks (who doesn't?). So this is much appreciated.
I'm on exactly the opposite end of the spectrum (and no one else seems to be supporting the full opposite position, so I may as well). I use use emacs with rainbow-identifiers-mode[1] enabled, which gives every variable a different color. I can't say for certain that it makes me more productive. I just turned enabled it on a lark when I installed spacemacs. But it's fun, and looking at code without it on seems somehow boring now. I'm definitely more comfortable with it on than with it off.
http://i.imgur.com/Q8D9dXz.png
1: https://github.com/Fanael/rainbow-identifiers
http://i.imgur.com/Q8D9dXz.png
1: https://github.com/Fanael/rainbow-identifiers
Nice experiment and I encourage any developer to tune up their tools so they are happy.
My experience is the opposite: I use syntax hilighting on Emacs, TextMate, and the JetBrains IDEs. When I SSH to a server and use Emacs to edit code, I find it jarring if syntax hilighting is not set up for whatever programming language I am editing. I can't read and understand the code as fast.
My experience is the opposite: I use syntax hilighting on Emacs, TextMate, and the JetBrains IDEs. When I SSH to a server and use Emacs to edit code, I find it jarring if syntax hilighting is not set up for whatever programming language I am editing. I can't read and understand the code as fast.
Making comments distinct from normal code is nice because you can easily alternate your focus on one or the other while reading through; and you're not likely to accidentally read commented out code as actual code. You're also not going to forget to close out your comment, for languages with paired comment delimiters.
Making strings highlighted makes it a little bit easier to ensure you're terminated your strings, especially in edge cases around escaping and quoted quotes (for languages that have a choice of quote characters).
Semantic highlighting - distinguishing identifiers based on their definitions - is a seriously niche win most of the time, where you're spending ever increasing amounts of CPU for a marginally actionable hint.