[weland]

I'm surprised and, to some degree, annoyed at the superficiality of some of the arguments in this debate. Like this one:

> Readability - You don't have to scroll over horizontally when you want to see the end of some lines.

It's not having to scroll horizontally that bothers me with long lines. My monitor is wide enough that it can probably hold 250 characters with ease. It's having to read long lines. Something is very bloody, terribly wrong in your code if you consistently find you need to write 150-character lines.

Besides, yes, monitors have gotten that wide that it's not an issue. Is there any serious reason to assume that code is the only thing I want displayed on my monitor at a given time? In a single window? That's as big as the monitor? The only moment when people had a good reason to be enthusiastic about that was the late 70s, when serial terminals appeared and teletypes began going the way of the dodo.

Also, who says the IDE is the only place where I want my code to be output? Maybe I want to grep on it or whatever. On an 80x25 terminal window because the least useful thing on earth is a huge monitor where I constantly alt-tab between a full-screen editor and a full-screen terminal.

[randallsquared]

"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.

[weland]

> 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.

IMO that's just compensating for the inadequacy of tools by making code harder to follow. Usefulness of code folding (and what it says about the code it's folding) aside, this is a really poor solution. If you just need that done temporarily, why not temporarily replace all the returns in the region you select, and then add them back when you're done? Any editor with search-and-replace can do that.

> 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,"

No, what I might say is "just stop thinking about the SQL query and the surrounding code in the same context".

Alternatively, put the SQL query in a separate function that conveys some meaning related to its purpose, so that people who read your code later don't have to decipher a 300-character query line in order to understand what that code is doing. They may not even be debugging that part of it, maybe something several layers of abstraction above borks and they end up in that part of the code debugging it.

> (easy to find a given key, but consumes lots of vertical space)

which can be easily averted with code folding? Or by simply scrolling down to the body of your code. Skipping entire lines is very easy, it's following a hundred-character snake that sucks.

[collyw]

> IMO that's just compensating for the inadequacy of tools by making code harder to follow.

Thats pretty much how I would describe the 80 character rule for old terminals. I find the occasional long lines can make things more readable. It certainly helps in locating the bit of code you are looking for when you can recognise it's shape.