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