[gav]

Fun fact: the VT-100 supported a 132-column display.

Anyway, there's a lot of advantages of trying to keep lines <= 78 columns wide. I don't make it a hard-and-fast rule, but usually overly long line is a sign that something's not right with the code and some refactoring is in order.

[pc86]

Why is a ~130-column line of code necessary a bad thing? I'm not saying it's good and that we should shoot for any specific number, but I don't see why shorter necessarily means better.

Disclaimer: I've been doing this for all of ~5 years so I have no experience with older terminal-style programming.

[scarmig]

Well, I'd say it's highly language dependent, and a matter of sane preceding white space rules. Going by column count, ObjC or Java would be a million miles away from, say, C or Haskell.

I would argue that that's a mark against the former, but if you're using languages like them it's silly to try and fit everything into 80 characters. You still need a strict rule, btw: sooner or later some jackass will be putting in 200+ if you're not careful, which is insane in any language because it's utterly unreadable.

It has to do with how the eye physically moves: you want a given block of logic to be as square as possible, so moving from one portion of it to another, on average, minimizes the amount of distance your eye has to travel.

[Deestan]

I generally disapprove of >80 width lines, but there are some cases in which they don't bother me, and that is boilerplate-ish code that you generally don't have to read all of to understand what it's for. For example macro-heavy C++ header definitions where each line ends in the same massive pile of definition.

The important bit for me seems to be that the stuff you have to read and understand should be in the <80 area.

[mje__]

Also, tools other than text editors - especially those designed to show code side-by-side like web-based code review tools (), etc become much harder to use when you have long lines.