Todays wonderful hardware allows us displays of great resolution. My desktop runs in 1280x1024, and I'm very grateful that it does. However I still keep my code formatted to 80 columns, the same width as a 25 year old DEC terminal. Why is this?
In a word, readability. I feel this to be one of the primary constraints of the programmer (after making the code work, of course; but even then readable code will make it easier to do).
We've all read about how readable code makes development much easier (I recommend the first chapter of The Practice of Programming). But one thing that is often neglected is that of long lines (over 80 columns).
As noted earlier, with modern displays, it is all too easy to resize a window to a larger width so that you can carry on typing on the horizontal. But take a look at what you're actually typing. Does it need to stretch that far over to the right? Could you make it smaller by merely inserting a newline at the appropriate point? Most modern languages such as C, Java and Perl are entirely devoid of context, so you can insert as much or as little whitespace as you need.
But why does having long lines affect readability so much, you ask? Surely, people reading your code can just resize their windows until they see it all, just like you did?
A nice thought, but a terribly self-indulgent one, and reminiscent of the "This page best viewed in netscape" buttons that were all over the Internet in 1995. The other person's display may not have the same capabilities as yours. Particularly if they have printed out your source to read offline, as most printers still adhere to the same 80 columns that they always have done. So, when they view your code, they'll either get a partial view of it and have to scroll to the right, or they'll get a beautifully offensive line wrapping effect, where the end of one line appears below the first one, completely ruining the effects of any indentation you carefully did.
As a further argument against long lines, I would like you to take a look at some printed matter nearby you. A newspaper or a book will do. Notice how many lines have extended length when compared to the main body of text? None. They are all formatted consistently, so that they eye can read them without losing context. If you have to start reading all the way over to the right, the subject matter is a lot more difficult to read than if it has a close context to the surrounding lines. You might think of the long lines as a visual distraction.
Now, for all my preaching, do I ever write long lines in my code? Well, yes, actually. It's not my intention to create an absolute law that must always be followed. I'd merely like to say think before you write a long line. Does it need to be that long? In the majority of cases, I think not. Try splitting it up. I think you'll be pleasantly surprised at how much more readable your code becomes.
Here are a few examples of good places to split up your code, to avoid making long lines and to increase the readability.
die "The file is not readable or executable or is empty" unless -r $file && -x $file && -s $file
Lines like this are very common in Perl code, because Perl allows post conditions (statements which are suffixed with and "if", "unless", "or die" or similiar). This code would however be much better if it was split into two lines as it would give more visual favour to the condition which is being tested for, rather than having it string out over to the right.
die "The file is not readable or executable or is empty"
unless -r $file && -x $file && -s $file
printf("%-40s %s %03d %5f", my_title, my_other_string, my_int, my_float);
Argument lists are another very common place to write long lines, in many languages, particularly C-derived ones. They can easily be split up without the use of backslashes.
printf("%-40s %s %03d %5f", my_title, my_other_string,
my_int, my_float);