The Paper History of Code Reading

How do you read code? It’s such a simple question that it seems obvious. You go to your IDE, select the class you’re interested in, and scroll up and down. You may also jump around the code using shortcut keys or mouse clicking to jump to the definition or usages of an identifier. There have been many papers over the years on improving the readability of code, but once you go back far enough, you start realising that a lot has changed. In 1986, Rambally tried different colouring schemes for keywords to enhance readability. They suggest reasons why this might not have been done before:

From Rambally's 1986 paper "The influence of color on program readability and comprehensibility" (ACM, public link), amusingly only available in black and white.
From Rambally’s 1986 paper “The influence of color on program readability and comprehensibility” (ACM, public link), amusingly only available in black and white.

Say what? Colour screens were becoming available at that time (quick digging shows CGA was 1981, and I believe Turbo Pascal 1.0 used colour in its launch in 1983; there were doubtless similar developments in Unix at that time), but the paper takes for granted that code is read on paper. This is referred to as an issue by Baecker and Marcus:

From Baecker and Marcus's 1986 paper "Design principles for the enhanced presentation of computer program source text" (ACM)
From Baecker and Marcus’s 1986 paper “Design principles for the enhanced presentation of computer program source text” (ACM)

Choice of font being dictated by its photocopyability is a long way from font choice on hi-res screens like Retina displays. This was a different era, and it means that some of the results are not necessarily applicable. For example, Miara et al summarise earlier work by Weissman as follows:

From Miara et al.'s 1983 paper "Program Indentation and Comprehensibility" (ACM, public link)
From Miara et al.’s 1983 paper “Program Indentation and Comprehensibility” (ACM, public link)

I think it’s safe to say that paper-page boundaries are no longer an issue with program reading!

Because of the paper focus, proposals for code navigation were also quite different. Where now we have things like outline views and jump-to-declaration, 30 years ago programmers were flicking backwards and forwards through piles of paper. So Oman and Cook’s idea of having a table of contents and an index must have been appealing, but the idea now of printing code into a book format is like asking for a hardcopy of wikipedia or a DVD of a youtube channel:

From Oman and Cook's 1990 paper "Typographic Style is More than Cosmetic"(ACM)
From Oman and Cook’s 1990 paper “Typographic Style is More than Cosmetic”(ACM)

It was also a different era of programming languages. I’m mainly looking in the mid 80s onward, so programs were entered via terminals not punched cards, but it’s the era of Pascal, FORTRAN and that whippersnapper C, maligned even then:

From Baecker's 1988 paper "Enhancing Program Readability and Comprehensibility with Tools for Program Visualization" (ACM)
From Baecker’s 1988 paper “Enhancing Program Readability and Comprehensibility with Tools for Program Visualization” (ACM)

This is historically amusing, given that C’s syntax was broadly copied into a very successful set of languages, like C++, Java, C#, Javascript and so on. The design of C was likely driven not so much by readability as by the Unix philosophy of reducing keystrokes. Just as you had “rm” instead of “remove”, you had “{” instead of “begin”. Languages tend to use shorter words for more frequent words, which reduces talking effort (less syllables) and writing and reading: less characters for the hand, and less width to travel for the eye. And what is shorter than one character? (Spoiler: zero characters! Dump those brackets…)

This era was also early in the structured programming era; several papers make mention of GOTO statements making the display of structured programming less effective.

Some of the papers, such as Miara et al.’s aforementioned study of indentation are using ALL CAPITALS MONOSPACE programs which are a bit horrendous to the modern eye. But the typography ideas were not all prehistoric; some of the pretty printing suggestions for the paper display of code were fairly advanced. I find it a bit too over the top, but Baecker and Marcus’ proposed display of code was an admirable effort at improvement:

From Baecker and Marcus's 1986 paper "Design principles for the enhanced presentation of computer program source text" (ACM)
From Baecker and Marcus’s 1986 paper “Design principles for the enhanced presentation of computer program source text” (ACM)

The margin notes and boxes are displays of comments in the original source. I think it ended up too busy, and some of the horizontal gaps are too large, but they do things like get rid of the curly brackets, use proportional fonts, the code is mainly lower case in the source, and they even do things like variable size brackets for grouping and variable spacing in expressions. Ultimately, it was the move from reading on paper into the modern standard of reading on screen that killed off this avenue of code display, to be constrained by character terminals and low-resolution graphics systems for the next ten to fifteen years. With modern displays, though, it’s worth considering some of these ideas again. Finally, we should beware citations of studies from this era when talking about screen-based reading; the paper-based results from that era may well not transfer to screens.

Advertisements

One thought on “The Paper History of Code Reading

  1. Old habits seem to die hard – I was astonished to hear someone suggest, just 2 years ago, that code reviews should be done on paper printouts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s