(In response to http://www.aaron-gray.com/line-limits/. Aaron is a great guy; let the reader visit his blog and learn from his wisdom.)

Yesterday after work I said that hard character line limits (often eighty characters, but not always) were a antiquated relic of the past. This was in playful response to a peer code review suggesting shorter lines. This morning I brought up line limits again as yesterday's banter didn't resolve anything. Our team lead weighed in, and now it looks like we will have some official guidelines.

For the record I'm not opposed to soft line limits (convention enforcement) in general, or even hard limits (tooling enforced) for specific projects. Below I've copied the main points from Aaron's post and responded to each inline.

80 characters is the natural length that the human eye can read without scanning. Once you pass that length, you have to scan, and the lines become progressively harder to grok.

Other factors are at play here. Font size, distance to the monitor, font face, color and lighting all effect scanability too. Besides shorter lines invariably result in more lines per idea (unless APL).

Long lines in a programming file are a code smell that you may be trying to do too much or be too clever on that line. Almost every time you can clean it up and make it easier to understand by extracting things to an explaining variable or using a named function to handle it. Or it could be a code smell that you are nesting too many if statements together because you're running out of room.

True, but I'm more interested in token count per line than character count per line.

Long lines in a view template likely means that you're not nesting attributes or tags as much as you could be. Or it could be a code smell that you're nesting too many tags inside each other and you should extract pieces into a partial / directive / etc.

Metrics such as line length and nesting should take a backseat to semantic markup and "correctly" respresenting data. For me there's no contest. If the lines really are unreasonably long, I have no problem with breaking between attributes.

Also because of the way browsers collapse whitespace between text elements and enclosing tags, I try to remove all space (including newlines) between tag delimiters and bare text. Sometimes this leads to lines that are longer than they otherwise would be and that is okay.

The advantage of setting an arbitrary line length means that your code will always look good when you use the features of a good editor like splits to view multiple files at once. This is because it forces you to wrap the lines at a human-readable point. If you simply set your editor to wrap lines for you and you try to use splits, it will make the code far more difficult to read because everything just jumbles together because the computer isn't smart enough to wrap the lines at a logical place in the code.

A good editor would insert soft wraps between tokens, though this doesn't bother me so much to stop using Vim.

If your code stops at 80 characters, its a lot easier to copy / paste a snippet onto a blog post or chat client.

I've never noticed this issue when using soft wraps. Anyway I'm pretty good with the keyboard, so even without soft wraps this isn't much of an issue for me. I suppose it might be for others.

If you contribute to Open Source projects, many of them enforce an 80 character line length.

I'm happy to conform when contributing to established projects. For my own projects and those that don't have a preference, I'd rather not restrict myself and just take it one line at a time.

It's important to note that people have different values. We all see the world a little differently. If you are leading a project, you get to set the rules; and if you are not, you should graciously follow them.