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.

A screen shot of my Sublime Text 3 set up for JavaScript code. This is what my Sublime Text 3 set up looks like for a random chunk of JavaScript in a Ruby on Rails app. I love the editor, and the color scheme is more or less a default set I found somewhere and really got into. Note the not quite black background. So lovely.

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 downloaded a new JavaScript library that highlights code for you [1], and I wanted to test it out. This post is just a marker for myself in some ways, as to why I even went around looking for such a library. Secondary goal: To make a reference to a GitHub repo in some semblance of an ACM compliant citation format (note the user @ after the author name).
  • 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

// Ohhh. Pretty code. Pretty...

function updateWindow() {
  $width = $(config.append_point).width()
    - MARGIN.left
    - MARGIN.right;
  $height = ($(config.append_point).width() * config.aspect)
    - MARGIN.top
    - MARGIN.bottom;
  d3.select(config.append_point).select("svg").remove();
  draw_heatmap();
}
// An attempt at responsiveness.
$(window).on("resize", function(){ updateWindow(); }).trigger("resize");

References

  1. Sagalaev, I (@isagalaev). 2014. highlight.js. GitHub, Inc. https://github.com/isagalaev/highlight.js.