In defense of unformatted source code – breakindent for vim

Everyone knows that Opera is better than Firefox,  Vim+Bash is better than any IDE, and 4-space indenting is better than tabulators. Having established those undisputed facts of life, let’s revisit some common fuel for flame wars: the mighty 80 character line limit.

 

80x10 "IBM Card" from 1928

Fortran code punched into a 80 x 10 IBM Card from 1928

 

Some people propose 80 chars, others 79, 100, 120, 132 , and many values in between.

Some people propose it should be a soft limit (meaning you can freely ignore in rare cases), while others set pre-commit hooks to stop any infringing line from reaching repositories.

None of this really matters.

The 80 character line limit, originated by hardware limits back when computer terminals were only 80 chars wide, or even further back in time, is said to provide many advantages. To name a few:

  • Better readability when opening two files side by side (for example, a diff)
  • Quicker to read (same reason why newspapers use many columns of text, instead of page-wide paragraphs: human brain scans text faster that way).
  • It forces you to extract code into separate functions, in order to avoid too many nesting levels.
  • It prevents you from choosing overly long symbol names, which hurt readability.
  • Etc.

I propose that those advantages are real and desirable, but should not be achieved through arbitrary line length limits. On the contrary, I propose that coders should not waste time formatting their source code: their tools should do it when possible. After all, we use text editors, not word processors! The problem is that, unfortunately, most text editors are too dumb.

Fix the editors, and you fix the need for line length limits.

 

If you edit your code in vim, you’re in luck, thanks to the Breakindent functionality. Here’s some side-by-side comparisons of 80-char line limit vs. unformatted text with BreakIndent enabled:

80x35

(left: 80-char                  right: breakindent)

Traditional terminal size:

Resizing your terminal to exactly 80 chars wide, both cases look pretty similar. Nothing to see here, move along.

 

 

208x16-26

(top: 80-char                     bottom: breakindent)

Wide terminal:

If you want to edit just one file, an 80-char limit will waste the rightmost half of your screen (or more).

 

 

 

40x50

(left: 80-char                   right: breakindent)

Narrow terminal:

If you’re three-way merging (or need to keep code aside for a moment, etc) those 80 chars will either wrap around or disappear from view, making the code harder to read.

 

 

All in all: when compared to an editor featuring smart indenting, the 80-char lines artificially limit how you can resize your own windows, with no appreciable gain, and in most cases forcing you to waste many pixels of your carefully chosen 27″ dual-screen coding setup.

Tags: , [en] | August 7th, 2013 |

Leave a Reply



Or manually insert your data below: