The PBP suggests using a 78-column line length.
I’m good with this. I don’t feel the need to be a pedant about it, but I like the idea in general.
The argument against it goes, “We have huge widescreen monitors, let me look at more things!” We do have bigger screens, and can easily go to 90, 100, 132, or even higher. (One of my co-workers suggested 200 characters, and showed it easily fit on his screen.)
I prefer the smaller number for several reasons, in vaguely order of importance:
- Just because you can write really long complex single lines doesn’t mean you should.
- If you’re indenting seventeen levels, your functions are extremely complex.
- Side-by-side diffs in some tools are lots easier to read.
- Printing becomes a problem.
- I like to run huge fonts.
- I like to have a pair of windows side-by-side.
- Some folks run their displays in portrait mode.
Compare the works of Karl Marx and of Ernst Hemingway. Both are well known authors, both wrote things which some people find fascinating. Karl Marx wrote in a time where text was flowery and sentences were long. Paragraphs of one sentence each are not uncommon for Marx, and stopping to really understand what he wrote is important, because there’s so much in each meaty sentence. Hemingway, on the other hand, would have had no trouble with Twitter, and wrote more short sentences. Which of the two is easier to read quickly and get meaning from? I want Hemingway-like code – clear, easily read, and understood by all. Line lengths can help encourage people to break complex statements up into more understandable components.
Another common argument against narrower line widths is that when you’ve got a complex function, you’ll be indented several levels, and only have a tiny space to write code in. I don’t think the problem is that you have a tiny space to write code in. Maybe the problem is that your function is too big. To me, this is a warning of bad design, not a narrow window.
Lots of tools use side by side diffs – p4diff, the venerable WinDiff, kdiff, etc. I think all these tools can be changed to use a vertical diff, but that’s a hassle, and a big change – side-by-side has advantages. It’s a lot harder to make it useful if you’ve got code half a block wide and are having to scroll back and forth.
In the Dark Ages of computers, engineers didn’t have a terminal, much less a workstation. They submitted a batch, and got back a printout. Code was written by hand, and read off print outs. Being able to print code was wildly important. We rarely print code today, but when we do, paper still puts a limit on the width code can be. Normal paper is not as wide as it is tall, and turning books sideways to read code is always odd. Narrower code is easier to print, easier to quote, easier to put on slides in presentations, and easier to share with others.
The last few wind up being personal preferences. Just as some can get 250 characters wide because they have a wide screen and small fonts, some don’t. It has been many moons since I coded on a physical terminal, but in that many moons my eyesight has degraded. My fonts are up past, “Large” and into “Huge” now. I like to run a pair of windows side-by-side, too, so that and huge fonts means I don’t get giant column widths… I get about 80. I know several engineers who run their monitors (or one of them) turned 90 degrees to portrait mode. Narrower, but lots more lines visible.
Any of these are good reasons to stick with less columns.
If a group wants to go otherwise, I don’t fuss too hard – my tools can help with this – but I do ask if we can reconsider. Generally, people have.