My pith helmet never left my head. The journey took weeks, crossed two major deserts, led through steaming jungles, and ended in a rather dull corporate campus, but it was worth it. I believe I’ve discovered a group of readers who are entirely oblivious to the appearance of a text, who read only content and are frankly blind to the form of the characters they read. In a series of carefully monitored tests, they were able to distinguish serif from sans serif faces less than 40% of the time. They are capable of reading six point all caps Helvetica set on a 50 pica measure without the least hint of complaint or eyestrain.
It’s something like discovering a stone age tribe in the middle of Manhattan, but these readers are engineers — software engineers.
What they read is code. Code comes in a variety of dialects — C, C++, PostScript, and Basic are all examples — and each dialect has its own set of reading rules. Because engineers fluent in a particular dialect know the rules for reading that dialect, the appearance of the characters in the code is of little importance. An engineer skilled in reading PostScript, for example, knows that PostScript variables cannot begin with a number, and would never misread “llx” as “11x.” *
In the old days (you know, ten years ago), only engineers read code, but these days, more and more just plain folks are trying to read it — if only to type it into a button on their family web page. Not only has the Web made code ubiquitous (thanks to HTML and JavaScript), but scripting systems (Visual Basic for Applications in Windows and AppleScript on the Macintosh) have lowered the “price of admission” to the world of code. People who would have run screaming from the room at the very mention of a “while loop” are now trying to enter code into their software applications.
Everywhere I look, I see code. And it’s almost always set in Courier.
Why Courier? The idea is to make reading the code easier for readers who don’t know the rules of reading a particular code dialect. Many non-engineers become obsessed with the spacing of the code as they try to type it — in spite of the face that spacing means very little to most modern programming languages. Using a monospaced font to set the code, the reasoning goes, makes it easier to enter the code. Courier is the most widely-available monospaced font, so it ends up being used to set code — almost by default.
Trouble is, Courier isn’t a very good font for setting code. But I’m getting ahead of myself. First, I’d better state my assumptions.
What makes a font good for setting code?
It should be a monospaced font. Non-engineers are very nervous about typing code, and panic when they see code set in a proportionally-spaced font (this is true even when the text accompanying the code explains that spacing isn’t important). I think code looks wonderful set in proportionally-spaced humanist sans serif faces, but it doesn’t work as well for the non-engineering reader. Adobe, for example, uses ITC Stone Sans and Stone Serif in its PostScript programming books — which can expect an audience of engineers — but every time I tried using it in my Adobe Magazine column (“Desktop Science”), I’d get lots of email messages from frustrated readers.
There should be good differentiation between numbers and letters. It shouldn’t be easy to possible to confuse an “l,” or an “I,” for a “1,” or an “O” for a “0.”
For printed publications, a compressed font is a good choice, because some lines of code can be very long. At the same time, these long lines often cannot be broken into several lines (though I have a method for dealing with lines you must break, see below).
For printed publications, avoid fonts with very thin strokes. For some reason, most of the code I’ve set ends up being printed on very cheap paper, which makes the thinnest strokes break up or drop out. Code is hard enough to read (for the non-engineer) — “sparkling” text won’t make it any easier.
Given the above guidelines, you can see why I think Courier isn’t a good choice for setting code. It’s too wide, its strokes often print poorly, and its differentiation between characters isn’t as good as it could be.
There are also quite a few different versions of Courier — and the spacing of the font varies from platform to platform (Macintosh and Windows), and between the different font formats (TrueType and PostScript Type 1). Sending pages of code set in Courier to an imagesetting service bureau for printing might result in your code being printed using a different version of the font than the one you used in your page layout program — which could result in changes to spacing and line-endings in your printed pages.
The perfect font for setting code
It’s taken me years, but I’ve finally found the perfect font for setting code. It’s TheSansMonoCondensed, by Lucas de Groot (available from FontShop San Francisco: (888) 333-6687 or (415) 512-2093. It shows good (though not perfect) differentiation between numerals and letters, it’s condensed, it’s available in a variety of weights, and it looks great.
Monospaced fonts and typography
Everything you know is wrong. In the topsy-turvy world of code typesetting, every typographic refinement you know is a mistake, not an asset. Quotation marks in code should be straight (you know — foot and inch marks), not curly. Double-dashes (used to indicate comments in some scripting systems) shouldn’t be replaced by em dashes. It’s a bad idea to use ligatures (if your page layout program features automatic ligature replacement, turn the feature off), or hanging punctuation (ditto), or automatic pair kerning (the fonts shouldn't contain any kerning pairs, but turn it off anyway, just in case). If you do find you need to range kern (or, in XPress, “track”) some of the text in a code example to get it to fit on the line or on the page, apply the same kerning value to all of the code in the example.
Code should always be aligned flush left — never centered, aligned flush right, or (heaven help us) justified.
Indicating replacement text
Sometimes, you’ll need to set part of a line of code in a way that indicates that the reader can vary a value as they enter the code. Most of the time, you’ll see the italic version of the font used for this purpose. Unfortunately, the italic versions of monospaced fonts look terrible. Instead, use a bold or semibold version of the font.
Indicating line breaks
Sometimes, it’s just not possible to fit all of a line of code on a single line in a printed publication. In these cases, it’s a good idea to add a symbol indicating line continuation (and add a note explaining what the symbol means).
Code is everywhere
Again, if all of our readers were software engineers, we wouldn't have to worry about the appearance of code in our publications. They really don't care (ask an engineer what's meant by "pretty" code printing, and you'll see what I mean). Many code dialects, however, have a wider readership — my grandmother knows something about HTML. Which means we have to take the same care when setting code as we do when setting any other kind of text — even though many of our usual typographic rules don't apply. I don't know how many times I've heard "just set it in Courier" — as if there were no other choice. If nothing else, I hope I've convinced you that there are other, better fonts for setting code. The point is not to make it *look* better (I doubt if code can ever be made beautiful), but to make it *work* better. Which, I always thought, is what typography is all about.
Or something like that. Deal?