I don't think anyone is saying to use long lines wantonly, just that they aren't such a scourge as they are made out to be. Most lines of code, I find, are naturally only a few tens of characters long, and I can't recall a single instance of seeing two 80+ character lines adjacent to one another. You can argue for some other points, perhaps, but I just don't think readability is a good reason -- certainly not if the alternative is to artificially format it in a way that is, arguably, just as unreadable, or to start abbreviating code structures and object names (which I don't think either of us would advocate, but which some people would undoubtedly do) to save characters.

You bring up a point of how other tools might present the source code differently, and that's true. However, I would say in response that I see this as a presentation issue, and something which the tool should handle better. I evaluated, for work last year, some tools we could use to pretty-print code as a PDF, and none of them handled long lines well -- some by truncating, some by naively word-wrapping with no attempt to preserve some kind of formatting, others by scaling the font size relative to the longest line in a section and the output page width. But its a tools deficiency. I shouldn't have to think about what some third-party tool does with my code, other the standard tool chain. Of course we can agree that one should consider specific requirements of specific tools if those tools are important to us, but working around tool limitations is a problem regardless because then we have to know our entire toolbox up-front to plan accordingly, or simply settle for the lowest common denominator.

Specifically you say:

[quote name='Bregma' timestamp='1357742829' post='5019458']
It's not hard to make your programming literate so it is understandable in any of these common formats as well as in your text entry tool. Using long lines is not one of the ways to do that.[/quote]

And I would argue just the opposite -- simply saying without specific merit or cause that all lines longer than an arbitrary limit are verboten does not aid overall readability. Remember that the alternative to "can't use, ever" is not "must use, always", but "can use, sometimes". I further argue that the natural structure of code, at least in any of the languages I use, is such that even the mere opportunity to create lines longer than 80 characters is so exceedingly rare (laying aside ridiculous streams of unrelated statements because C++ et al allows me to) to be almost a non-issue.

Sometimes the most legible or 'literate' thing to do is to allow for an occasional long line, rather than to force some unnatural structure upon it.

There likely is some reasonable upper-bound, but I'd wager its quite a bit north of 80 characters -- even the box I'm typing in now, on a website, in a frame, with margins at the side, in an application window which is not fullscreen, all on a not-particularly-wide 1080p screen, displays about 120 characters comfortably in a fixed-width font.

I try to keep my lines to 70 characters or less. It means I don't have to scroll sideways to read the line when I'm splitting the screen in VS.

I find really long lines to be jarring as I try to read code. The eye settles into a back-and-forth of a few inches and then suddenly here's a line of 3 or 4 times the length. It breaks the process of reading smoothly.

I also find that super-long lines are either doing too much (doing math in arguments, etc) or else the function itself is designed to accept too many parameters. If a function needs a ton of information I prefer to package that as a POD struct and also ask questions about whether or not the function is doing more than it should. There are certainly cases where a function can need a lot of information, but I think not as often as certain APIs would indicate. Trying to figure out all of what such a function is more difficult as well since you have to sort of hunt down the commas or unfold the parenthesis (or whatever) mentally.

I don't know if there's really a magic number to it, but a kind of smoothness to the code body is what I hope for.