In defense of the 80-column rule

Early in my career when most computer terminals were low-resolution affairs capable of showing only a limited number of characters, and many monitors, such as the famous VT100 series, were restricted to 80 columns of text. Thus it made perfect sense for programming projects to adopt the programming convention that all code should be formatted to fit within 80-columns or even shorter. This convention not only made sense because of restrictions of the display technology but also to help make the code look good when printed out, which was a frequent occurrence in an era of small displays and slow compilers.

I have adopted this convention for many years on projects in which I have been involved, and have long taken it for granted. However, lately I have been spending time looking at Java source code for various Eclipse plug-ins and have been surprised to find that it is not clear that this code follows any restrictions of line lengths whatsoever. I have even seen some code with lines of more than 160 characters! It is clear that there must be developers who feel that the size and resolution of modern computer displays removes the need for any restriction and who do not understand that there are still many legitimate reasons for limiting the width of their code. So I feel compelled to rant a little bit on why I believe this convention is still justified.

Here are my reasons, in no particular order:

• Limits eye-movement while reading code.
  
  While the full field of human vision is fairly wide, the area in which words can be read is restricted to close to the center of vision, thus the eye needs to move in order to read text. The farther the eye needs to move to read, the more effort is required. Reading text with excessively long lines generally results in lower comprehension and greater eye-strain. This is why text in newspapers and magazines is formatted in narrow columns. The same principle applies to code as well.
  
  
• Avoids need for horizontal scrolling when viewing/editing code.
  
  If the code is wider than your editor, you must horizontally scroll it to read it or edit it. This is obviously tedious. Developers will be forced between sacrificing screen real estate for wide editor panels or having to scroll.
  
  
• Allows use of side-by-side text editors.
  
  If the code is restricted to a reasonable width, then developers with large enough monitors can place editor panels side-by-side on a regular basis. With an 80-column restriction and using an 9-point font (I prefer proggy tiny with bold punctuation), I can fit two editors side-by-side on my 17" laptop with horizontal room to spare for other Eclipse views. On my large 30" display at work I sometimes show three side-by-side editors.
  
  
• Facilitates use of graphical diff viewers.
  
  A related issue is the use of side-by-side graphical diff tools such as kdiff3 (which I favor because of it support for comparing directories). When comparing overly wide source files using such tools, you are forced to horizontally scroll both files in order to fully visualize the differences. The problem is even worse when performing a 3-way merge using these tools.
  
  
• Allows developers to standardize their development environments editor width.
  
  If developers know that all the code they work with will be restricted to a reasonable width, they can configure the views in their development environment accordingly and will not be forced to resize editor views to accommodate differing code widths.
  
  
• Ensures code will print out nicely.
  
  Although it is much less common to print out code than it once was, it can still be useful from time to time. Code that is too wide will not print out nicely. Depending on your printer settings, the excess width may be automatically wrapped, truncated, or printed on extra sheets of paper. None of these are desirable and make the code hard to read when printed out. I find that code following an 80-column restriction can legibly be printed out  in a small font with two-pages per sheet of paper (e.g. on linux, I usually use the command enscript -2r -G to print out code).
  
  
• Discourages developers from using overly complex nested code.
  
  Deeply nested code is generally considered more complex and harder to understand than shallowly nested code. This is not a hard and fast rule, but generally speaking deeply nested code should be avoided. Putting a restriction on the width of the code, together with reasonable indenting and code formatting rules will naturally discourage excessive nesting.