Home >

My Case for 70 Columns and 2 Spaces

My Case for 70 Columns and 2 Spaces

The ideal number of columns and whether to use tabs or spaces are frequent topics of debate among programmers. In this post I justify my preference for 70 columns and 2 spaces.

Posted on February 15, 2017 by Ernesto Garbarino

As many other people of the same age, I grew up with 40-column computers (C64, ADAM Coleco) and even less in the case of the TK-90X —a ZX Spectrum clone. Many years later, I migrated to 16-bit machines like the Amiga and the IBM PC clones that provided 80 columns as the standard.

For many years, the tab key was for me just an odd key that made the cursor jump unexpectedly until I became a more “serious” programmer—not really—and found out that I could align my code by just pressing one key. I immediately had that Eureka moment that revealed the whole raison d’être for such an odd key.

It was difficult to figure out, for quite a while, why anyone in good mental health would hit the space bar four times to achieve what only takes one key stroke using the tab key; let alone, pollute source code with spaces which is not the same as the \t character whose aim is to align code rather than to separate operators or arguments.

But not only I grew up as a computer geek, but also as a freelancer tech writer for a newspaper. I would write my articles using WordPerfect in MS-DOS using 80 columns but then my articles would be split up into 6 columns, each having less than 30 characters. Since I was writing a series of C Language tutorials, this was a problem since I had to use short function names in order to avoid hyphenation.

An article formatted in columns
An article formatted in columns

I had a heated argument with my editor; I asked to have the exception of being able to have my articles being printed verbatim without breaking them into columns. The editor explained to me:

“Look, the choice of arranging text into multiple columns with a few characters per row is not some arbitrary tradition; it has to do with the fact that it is difficult for people to find the next line below with their eyes when rows are too long. It is faster and more pleasant—and efficient—for people to read text arranged into narrow columns.”

Since then, I became self-aware of this fact, and that, indeed, I was able to tell that I was able to read newspapers faster than I could read novels, and that, in turn, I could read novels faster than I could read 80-column text on the screen.

It was not that 6 columns, each having less than 30 characters in width, were arbitrary on newspapers, but that 80 columns on the computer screen were, instead, the arbitrary configuration.

See, in a typical 8-bit computer like the C64, 1000 bytes would be allocated for storing characters for 40 columns and 25 rows. The PC then simply doubled the horizontal number of characters to 80 by allocating 2000 bytes rather than 1000. The first IBM PC, the 5150, had just 16Kb of memory. The cost of memory was at a premium still in the early 80s. The 5150 even booted in 40 column mode by default, apparently.

We can see that the 80 column mode was simply the result of computer designers breaking up limited memory into an array of characters that fit the 4:3 CRT monitors of the day. Note also that in printed media, not only we have always used less than 80 characters, but also longer heights as opposed to longer widths—16:9 screens are the other way around.

Modern source code editors provide a bit of relief when doing the “mental carriage return” by showing line numbers and highlighting the current line, so it is not that 80 columns is “too long” in this sense. All I wanted to convey is that there’s nothing “normal” about 80 columns as far as the ideal number of columns for humans is concerned in terms of readability.

I have settled for 70 columns for my own code because of two reasons. The first is that I do not always have the luxury of sitting at my desk in front of a massive 26 inch monitor—my default is a laptop screen. So far so good; even reading 80 columns on a 11 inch Macbook Air is still acceptable. The second reason (which takes the first as a constraint) is that, most of the time, I am working on two files side-by-side. This means that my laptop’s screen real state halves and each half of the screen is even further reduced if window borders, line numbers and scroll bars are accounted.

Two source files side by side on a 14" screen using 70 columns and 2 spaces
Two source files side by side on a 14" screen using 70 columns and 2 spaces

80 columns is OK for working with one file at a time, but text has to become way too small for my eyes if I wanted to work on two files at the same time. My choice of 70-columns is a compromise which now prompts me to explain my choice for two spaces—rather than four spaces or tabs.

In the tabs versus spaces war I firmly believe that tabs should have won. Using tabs abides to the “separation of concerns” principle. Tabs are for formatting, spaces are syntactical tokens (e.g. function application in Haskell). The choice of spaces over tabs is a social issue rather than an engineering one. We use spaces because of the potential discrepancy in settings between the editor used to create the source file and that used to edit it by a second person. In order to use spaces as efficiently as tabs (e.g. hitting the space bar multiple times is mental) we have to rely on smart editors or IDEs that interpret spaces as tabs.

Because I don’t live in an island and I have to share my code and read other people’s, spaces is unfortunately the de facto choice. Now, why two spaces and not four? Two spaces is not ideal from a legibility perspective since it is harder to quickly tell column alignment which is key in layout-based languages such as Python and Haskell. Yet, I have settled for two columns because it is extremely challenging to write readable, well-formatted code code in 70 columns using four spaces.

The disadvantage is that opening someone else’s code may require me to do sideways scrolling, wrapping and/or opening just one file at at a time. It may also take a bit more cognitive effort to tell columns apart when using two spaces in layout-sensitive languages.

Last but not least, few people will realise at a first sight that your code does not go beyond 70 columns. Most people will just assume that it is code “within the 80-column standard.”.

In conclusion, if you work on a laptop and use layout-based—as opposed to curly-braces—languages, I strongly recommend that you challenge the 80-column/4-spaces convention and try 70 columns with 2 spaces instead; your eyes will be grateful.