Syntax Highlighting Off

https://www.robertmelton.com/2016/02/24/syntax-highlighting-off/

by clishem • 10 years ago

152 106 10 years ago

johansch• 10 years 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?)

cookiemonsta• 10 years 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.

scottLobster2• 10 years 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.

mchahn2• 10 years 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.

cLeEOGPw2• 10 years ago

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.

adrianN• 10 years 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.

gkya• 10 years 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.

onion2k• 10 years 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.

SixSigma• 10 years 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/

mavelikara• 10 years 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.qmu...

watchdogtimer2• 10 years ago

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

majewsky2• 10 years ago

Re 2)

  set wildmode=list:longest

EDIT: Re 3), there's something weird going on.

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.

marcosdumay• 10 years ago

Well, not ed, but refactoring Haskell code with sed incredibly nice.

Pirate-of-SV• 10 years 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.

regularfry• 10 years ago

That does depend where you sit on the spectrum between wanting ubiquitous commenting and believing that comments are themselves a smell.

GavinMcG• 10 years ago

Why does the author having different preferences have anything to do with his credibility?

dumbguy2• 10 years 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• 10 years ago

If your comments lie, you're doing it wrong.

Cthulhu_• 10 years 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.

mchahn2• 10 years 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• 10 years 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• 10 years 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.

seanmcdirmid2• 10 years 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• 10 years 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.

userbinator• 10 years 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.

prezjordan• 10 years 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• 10 years 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_• 10 years 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• 10 years 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

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_klev2• 10 years 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• 10 years 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.

cxa• 10 years ago

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.

barrkel2• 10 years 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• 10 years 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• 10 years 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.

nicholaides• 10 years ago

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

barrkel2• 10 years ago

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.

ninkendo• 10 years ago

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.

noir_lord2• 10 years ago

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.

marssaxman2• 10 years ago

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?

ggustafsson• 10 years 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

black_knight2• 10 years 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• 10 years 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• 10 years ago

It can also help when jumping around between many different languages, especially when they are similar.

clishem• 10 years ago

Interestingly enough, the author of the article notes that it has become easier for him to jump around different languages.

whack2• 10 years 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• 10 years 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.

whack2• 10 years ago

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.

pjmlp3• 10 years ago

It is an hipster thing, coding without syntax highlighting, no completion, only CLI and the original Vi.

shitgoose2• 10 years ago

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.

black_knight2• 10 years ago

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.

enqk• 10 years 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/

"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• 10 years 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.

scottLobster2• 10 years 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.

crdoconnor3• 10 years 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.

lokedhs• 10 years ago

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.

majewsky2• 10 years ago

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}

I often found myself properly formatting the code before I could even read it.

pjmlp3• 10 years 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.

kevinSuttle• 10 years 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/

agumonkey• 10 years 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• 10 years 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• 10 years 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• 10 years 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.

percept2• 10 years 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_klev2• 10 years 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• 10 years 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.

shitgoose2• 10 years ago

went dark years ago, never looked back.

"one year something changed - I don't know exactly what" - you matured:)

percept2• 10 years ago

Have not--how dare you!

auggierose• 10 years 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) 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• 10 years 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• 10 years 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• 10 years 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• 10 years 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.

cLeEOGPw2• 10 years 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.

plg• 10 years ago

let's have a version for emacs !

lamontcg• 10 years 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_lord2• 10 years 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.

mst2• 10 years 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.

mst2• 10 years 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• 10 years 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.

mrottenkolber2• 10 years ago

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

kittxkat• 10 years ago

I really like that colorscheme, care to share it?

mrottenkolber2• 10 years 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.

dave20004• 10 years 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• 10 years ago

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

z5h• 10 years 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• 10 years 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

1: https://github.com/Fanael/rainbow-identifiers

mark_l_watson• 10 years 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.

Syntax Highlighting Off

Related Stories