Line length in programming

I used to think that 80 (or even 100) characters was too short, but I've changed my mind for two reasons:

1. Like you said, splitting windows. I now use a tiled window manager and also I use vim splits a LOT. If I can fit two windows side by side, good - if I can fit three, great!

2. I find that when my lines go over 80/100ish characters they are very hard to read anyway (too much eye travel between lines) and its usually (though admittedly not always) a sign that my code is too nested or otherwise could be simplified.

So now I happily use 80 character lines (When using Python I strictly follow the vim PEP8 checker, for example). I actually kinda prefer 80 to 100 now because I use slightly above average font sizes (I don't have the best eyesight) and this way I can still comfortably fit two editors side by side.

Touche. Multiple monitors and more screen real estate has been proven to increase productivity. It's an easy win.

If the lines come out too long too often, it may be a symptom of other problems.

  if ((browser.OS == 'win') && (browser.userAgent == 'IE')) {

  isIE = (browser.userAgent == 'IE');
  isWindows = (browser.OS == 'win');
  if (isIE && isWindows) {

I quite like 100 chars: it's perfect for two side-by-side windows on my screen. (i.e. two adjacent emacs buffers are about 101 chars wide each.)

Please take the time to review and correct this sentence next time you copy-paste. This is a painful read.

"Something is very bloody, terribly wrong in your code if you consistently find you need to write 150-character lines."

Not necessarily.

Most lines are below 80 characters, but there are good reasons (for readability!) to use longer lines from time to time: vertical space is more precious than horizontal on modern screens, and the more content I can fit into each vertical page, the faster I'll understand what I'm looking at.

The main reason I like the ability to occasionally have a 150 or 180 character line is akin to code folding, which some editors have as a feature. The feature allows you to hide a function or class by collapsing it into one line, because you want an overview of the code around it or calling it, and for the moment the implementation details aren't relevant. Now, I don't actually use the code folding feature in practice, mainly because I find that the times I would want to use it are times when I nearly always want to fold the code, and in a case like that, it's nice to be able to "pre-fold" it by putting it all on one line.

For example, if not using an ORM, I might want to use SQL to grab some results from a db (in a model, say), and I almost never want to think about my SQL and my surrounding code in the same context. Now, you might say, "Just put that SQL in its own method with a reasonably short name, and call it where you would otherwise have a long SQL string, and in the function that returns it, you can break each line at 70-80 characters," but that seems like a "solution" which improves nothing in my typical reading of the code, and requires me to jump around to find the SQL in the rare case I need to pay attention to it. It breaks up something which is naturally local and specific to this place in the code.

Another example which happens somewhat more frequently for me is when I want to use a literal object in JS. If I want to keep the definition local -- because, perhaps, nothing outside of this function ever needs it -- my choices are to put each key/value pair on its own line (easy to find a given key, but consumes lots of vertical space), to put multiple key/value pairs on each line to fit ~80 characters (both moderately difficult to find a given key, and still eats moderate amounts of vertical space), or to "fold" it all to one line (consumes the minimum vertical space, with the trade-off that it's difficult to find a given key). The most common case of this is where I have the choice between using 4-6 lines, or one line, and it's an easy choice for me to pick one line, though I've never encountered a coding standard that agreed with me.

I thought the historical reason was that punch-cards had 80 characters per line.

...just Googled it: http://programmers.stackexchange.com/questions/148677/why-is...

That is a straw man. No one actually thinks 80 character displays are the reason to use 80 characters.

I think 80-100 is fine. More than 100 and you probably need to refactor the line some, because you probably have too much logic on a single line (or you need to choose names that aren't hugely long).

You don't use a split screen in your editor?

I've never had much issue keeping Python code under 80 columns. Going beyond usually means you've used way too many nested clause and should either rewrite the whole thing or extract part of its to subroutines.

Bingo. To quote Captain Jack Sparrow, style guides are "more what you'd call guidelines than actual rules".

They're not a substitute for common sense, and sometimes breaking the rules is for the greater good. I find the similar situations in shops that enforce strict naming conventions.

edit: The other tip is that the 80 character limit is closely aligned to the optimal line length for regular reading: http://ux.stackexchange.com/questions/3618/ideal-column-widt... A bit more than normal is allowable for programming because of indentation and the more structured nature of the text.

For what it's worth, in my opinion, if you need more than an 80 character line in Python, you're doing it wrong.

I currently maintain a large Python codebase where the original authors /needed/ big long lines. Anytime I see one of these big wads of bubble gum, I know I can rewrite it to be simpler, clearer and shorter (I've done it enough now). Fortunately, there are increasingly fewer of them...

It's important to remember that you're not just writing for the computer -- while it can take almost anything syntactically correct that you throw at it -- some human, somewhere will still have to read and understand that code.

It may be you, six months later.

What doesn't help is silly idioms in some environments where most of the lines written START at 2 or 3 indents deep because they're inside a method inside a class inside a namespace that are all indented.

===

If anyone's interested, I wrote a simple command to scan files for configurable line length violations and the presence of a file-terminating line ending.

https://github.com/frou/pagecop

(yes, I'm aware it could probably be duplicated with some sed/awk wrangling!)

The main argument for me, additionally to what you describe, is keeping lines readable. There is a reason the books from 1000 years ago were made vertical. They could have used much more width and characters per line but they didn't. See the newspaper format as well with multiple columns. The eye struggle to follow a text that is too wide.

For me, 80 chars is an arbitrary but acceptable limit (I could even argue it should be even shorter).

Personally, I view verbose languages that needs longer line as bugs. If you look at Scheme for example, it lets you wonderfully indent and nest, so that you rarely need long lines. Everyone benefits from it. Shorter lines are better for the brain, the problem is when coding languages make line too long by design, forgetting the 1000 years of experience in typography we've accumulated.

Code is read far more than it is written. Therefore code legibility is important. Line length affects code legibility. Therefore line length is important.

IMO, given that most blog templates include copious margins, many don't allow readers to resize the text, and some don't even allow readers to scroll horizontally, 80 characters is far too long for a line of code in a blog post.

Or python if you're already in a function in a function in a class (so 68 chars left). If you also standardised on importing modules, not classes things can get silly. My favourite counter-example to the 80 char limit was a line in openstack which was:

    return some_loaded_module.fairly_descriptive_but_necessarily_long_name(not_very_long_argument)

    fdbnln = some_loaded_module.fairly_descriptive_but_necessarily_long_name
    return fdbnln(not_very_long_argument)

Is Java still lacking constructs like

     var thingy = FactoryFactoryObjectThingymybobProducer

That's a far more sensible response than the OCD like attitudes of some commenter’s here.

I just had a quick look at that grammar article. I imagine when people are describing something technical / scientific / difficult to comprehend, it will take more words.

Wow, I do the exact same thing. Nice to see someone else doing the same.

The information on how to configure emacs to highlight lines that are too long was new to me.

I presume it is on the front page because it has got several up votes in its first half hour.

exactly, however, when you point this out, the "cool" community votes you down quickly :)