Syntax highlighting and the art of visually decoding code
I remember what programming through a monochromatic terminal emulator was like. It was awful. I rejoiced when I discovered Emacs could be configured to respond properly to the cursor error keys on my keyboard, without tangling my terminal into a knot of line wraps slathered in a character buffer dump. Using whitespace was the only way to maintain any semblance of sanity when reading code. It was a dark time.
Microsoft came to campus one year and started handing out free versions of .NET Visual Studio (I think it was version 7 or something that is by now ancient), and I remember being blown away by the color/style highlighted code. I did a hard blink and twitched a little, if I remember correctly. The global variables were bold and green, reserved language keywords were italicized and purple, and – good lord – comments were just the right shade of light gray to be readable, but also easily ignored when skimming through files. It was marvelous, and I’ve never gone back.
On syntax highlighting that is, not Visual Studio, which nowadays, I could take or leave it.
Yup… [Stretches old man bones] We’ve come a long way since those days. In fact, nowadays, the mark of a software deseigner/developer is the confetti colored text against a dark background that isn’t quite black. You can call it out from across a coffee shop. That’s not just a draft screenplay about two friends backpacking across Eastern Europe that that squirrelly guy is writing. It’s computer code… [Hushed awe fills the space]
But everyone’s got a different set up. This isn’t a post about editor/language wars, or which color scheme is best for rendering whatever it is a person may be hacking out. Ultimately people are going to work in an environment that fits their needs, whatever those may be. But! But, people share code on the web, and when they do their goal isn’t to make the goal look the way they want, but to present it in a way that works for the most people.
So, what this post is about is two things:
- I’m interested in setting up some A/B tests to see if there are patterns to how people consume code when it’s presented in a variety of way. I’ve seen similar research conducted for other facets of site design (and content publishing in general), but I think there’s a better way to do it. I’m going to start exploring the ideas here. This is step one.
Some random code
- Sagalaev, I (@isagalaev). 2014. highlight.js. GitHub, Inc. https://github.com/isagalaev/highlight.js.