11 ms·

Syntax Highlighting Off

152 points by clishem 11y ago

pjmlp 11y ago
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.
plg 11y ago
let's have a version for emacs !
userbinator 11y ago
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.
deleted 11y ago
[deleted]
prezjordan 11y ago
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.
vbezhenar 11y ago
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.
_ph_ 11y ago
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.
- frou_dh 11y ago
  > 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 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.
  - teh_klev 11y ago
    > 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.
- gdwatson 11y ago
  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.
barrkel 11y ago
I'd freely speculate that 90% of the benefit of syntax highlighting comes from mere lexical highlighting - specifically, making comments, strings and keywords visually distinct from everything else. And even keyword highlighting is very secondary to the first two. 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.
- justifier 11y ago
  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: 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) for highly configurable designs just pulling flags from the command line will get out of hand quickly but it would be superficial to have a function that allows the user to see the programs state and alter it to their needs
- pmoriarty 11y ago
  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.
deleted 11y ago
[deleted]
ggustafsson 11y ago
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 https://github.com/ggustafsson/Static-Color-Scheme
- black_knight 11y ago
  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.
legulere 11y ago
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.
- paulryanrogers 11y ago
  It can also help when jumping around between many different languages, especially when they are similar.
  - clishem 11y ago
    Interestingly enough, the author of the article notes that it has become easier for him to jump around different languages.
whack 11y ago
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.
- coldtea 11y ago
  >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.
  - whack 11y ago
enqk 11y ago
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/ 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.
philbo 11y ago
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.
- scottLobster 11y ago
  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.
  - crdoconnor 11y ago
    >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.
    - dave2000 11y ago
      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.
johansch 11y ago
"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?)
- scottLobster 11y ago
  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.
- cookiemonsta 11y ago
  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.
- mchahn 11y ago
  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.
adrianN 11y ago
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.
- marcosdumay 11y ago
  Well, not ed, but refactoring Haskell code with sed incredibly nice.
- onion2k 11y ago
  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.
- gkya 11y ago
  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.
- SixSigma 11y ago
  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/
  - mavelikara 11y ago
    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". [1]: http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/ http://web.archive.org/web/20080103071208/http://www.dcs.qmu...
Pirate-of-SV 11y ago
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.
- dumbguy 11y ago
  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.
  - iconjack 11y ago
    If your comments lie, you're doing it wrong.
    - dumbguy 11y ago
      Not a lot of team experience I'm guessing?
- Cthulhu_ 11y ago
  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.
  - mchahn 11y ago
    > 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.
massysett 11y ago
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.
- wodenokoto 11y ago
  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.
- seanmcdirmid 11y ago
  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.
  - hga 11y ago
    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.
    - seanmcdirmid 11y ago
      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.
kevinSuttle 11y ago
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/ http://www.wired.com/2011/01/the-benefit-of-ugly-fonts/
agumonkey 11y ago
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.
richard_todd 11y ago
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.
- jstimpfle 11y ago
  nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax on \| endif \|<cr><C-g> nmap <F12> :set wrap! wrap?<cr> My personal productivity boost :)
api 11y ago
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.
percept 11y ago
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.)
- teh_klev 11y ago
  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.
- bluedino 11y ago
  >> 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.
- shitgoose 11y ago
  went dark years ago, never looked back. "one year something changed - I don't know exactly what" - you matured:)
  - percept 11y ago
    Have not--how dare you!
auggierose 11y ago
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 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.
megalodon 11y ago
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.
Pxtl 11y ago
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.
pklausler 11y ago
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.
KingMob 11y ago
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.
- cLeEOGPw 11y ago
  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.
lamontcg 11y ago
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.
- noir_lord 11y ago
  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.
  - mst 11y ago
    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.
- mst 11y ago
  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.
- y4mi 11y ago
  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.
mrottenkolber 11y ago
I do something very similar (grey strings/comments, some bold/underline identifiers): http://i.imgur.com/i5j0QKT.png http://i.imgur.com/i5j0QKT.png
- kittxkat 11y ago
  I really like that colorscheme, care to share it?
  - mrottenkolber 11y ago
    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)))) Other than that I use the Inconsolata font.
dave2000 11y ago
"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.
- masukomi 11y ago
  ... sorry but syntax highlighting on spoken languages for parts of speech would be CRAZY useful when learning to read that language.
deleted 11y ago
[deleted]
mark_l_watson 11y ago
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.
z5h 11y ago
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.
bjterry 11y ago
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 http://i.imgur.com/Q8D9dXz.png 1: https://github.com/Fanael/rainbow-identifiers https://github.com/Fanael/rainbow-identifiers

152 points by clishem 11y ago

pjmlp 11y ago

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.

plg 11y ago

let's have a version for emacs !

userbinator 11y ago

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.

deleted 11y ago

[deleted]

prezjordan 11y ago

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.

vbezhenar 11y ago

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.

_ph_ 11y ago

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.

frou_dh 11y ago
> 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 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.
- teh_klev 11y ago
  > 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.
gdwatson 11y ago
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.

barrkel 11y ago

I'd freely speculate that 90% of the benefit of syntax highlighting comes from mere lexical highlighting - specifically, making comments, strings and keywords visually distinct from everything else. And even keyword highlighting is very secondary to the first two. 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.

justifier 11y ago
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: 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) for highly configurable designs just pulling flags from the command line will get out of hand quickly but it would be superficial to have a function that allows the user to see the programs state and alter it to their needs
pmoriarty 11y ago
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.

deleted 11y ago

[deleted]

ggustafsson 11y ago

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 https://github.com/ggustafsson/Static-Color-Scheme

black_knight 11y ago
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.

legulere 11y ago

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.

paulryanrogers 11y ago
It can also help when jumping around between many different languages, especially when they are similar.
- clishem 11y ago
  Interestingly enough, the author of the article notes that it has become easier for him to jump around different languages.

whack 11y ago

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.

coldtea 11y ago
>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.
- whack 11y ago

enqk 11y ago

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/ 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.

philbo 11y ago

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.

scottLobster 11y ago
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.
- crdoconnor 11y ago
  >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.
  - dave2000 11y ago
    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.

johansch 11y ago

"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?)

scottLobster 11y ago
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.
cookiemonsta 11y ago
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.
mchahn 11y ago
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.

adrianN 11y ago

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.

marcosdumay 11y ago
Well, not ed, but refactoring Haskell code with sed incredibly nice.
onion2k 11y ago
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.
gkya 11y ago
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.
SixSigma 11y ago
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/
- mavelikara 11y ago
  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". [1]: http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/ http://web.archive.org/web/20080103071208/http://www.dcs.qmu...

Pirate-of-SV 11y ago

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.

dumbguy 11y ago
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.
- iconjack 11y ago
  If your comments lie, you're doing it wrong.
  - dumbguy 11y ago
    Not a lot of team experience I'm guessing?
Cthulhu_ 11y ago
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.
- mchahn 11y ago
  > 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.

massysett 11y ago

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.

wodenokoto 11y ago
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.
seanmcdirmid 11y ago
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.
- hga 11y ago
  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.
  - seanmcdirmid 11y ago
    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.

kevinSuttle 11y ago

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/ http://www.wired.com/2011/01/the-benefit-of-ugly-fonts/

agumonkey 11y ago

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.

richard_todd 11y ago

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.

jstimpfle 11y ago
nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax on \| endif \|<cr><C-g> nmap <F12> :set wrap! wrap?<cr> My personal productivity boost :)

api 11y ago

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.

percept 11y ago

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.)

teh_klev 11y ago
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.
bluedino 11y ago
>> 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.
shitgoose 11y ago
went dark years ago, never looked back. "one year something changed - I don't know exactly what" - you matured:)
- percept 11y ago
  Have not--how dare you!

auggierose 11y ago

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 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.

megalodon 11y ago

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.

Pxtl 11y ago

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.

pklausler 11y ago

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.

KingMob 11y ago

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.

cLeEOGPw 11y ago
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.

lamontcg 11y ago

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.

noir_lord 11y ago
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.
- mst 11y ago
  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.
mst 11y ago
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.
y4mi 11y ago
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.

mrottenkolber 11y ago

I do something very similar (grey strings/comments, some bold/underline identifiers): http://i.imgur.com/i5j0QKT.png http://i.imgur.com/i5j0QKT.png

kittxkat 11y ago
I really like that colorscheme, care to share it?
- mrottenkolber 11y ago
  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)))) Other than that I use the Inconsolata font.

dave2000 11y ago

"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.

masukomi 11y ago
... sorry but syntax highlighting on spoken languages for parts of speech would be CRAZY useful when learning to read that language.

deleted 11y ago

[deleted]

mark_l_watson 11y ago

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.

z5h 11y ago

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.

bjterry 11y ago

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 http://i.imgur.com/Q8D9dXz.png 1: https://github.com/Fanael/rainbow-identifiers https://github.com/Fanael/rainbow-identifiers