in reply to 78/80 chars perl line still a meaningful rule
Thirty years ago I would have given you a different answer. Today, I think that most source-code lines already do fit within a “reasonable” length, such that, if they don’t, they are probably already hard-to-read for reasons other than just the number of characters in the line.
A very common example is: subroutine calls. You can have very long lists of parameters there, sometimes. Although I tend to prefer using a single hashref instead, “existing-code is what existing-code is.” That’s where you encounter length ... and a choice site for breaking the call into multiple lines, perhaps with comments. Even so, what you are trying to simplify is not so much “scrolling from left to right,” but “counting commas.” Ultimately you are trying to improve at-a-glance clarity, not merely to reduce line length.
Character strings: write several shorter literals and concatenate. Better yet, write a shorter error-message to begin with, because you’d prefer that the user actually reads it.
So, to me, this isn’t a “rule,” i.e. strictly concerned with length and/or saying that you have actually made the code “better” just by folding the lines.
As I said in the other post, you can really hose up a file, in terms of the source-code control system, if you reformat the whole thing, because you have just wiped-out the history of source-code changes to a particular area. Hence, I advocated selective reformatting of particular problem areas (with prior agreement from your management and from all of your colleagues!) and checking-in those revisions separately, having made no other changes in the same commit. Sometimes, the continuity of per-line history through a particular hot-spot is more important than [e.g. as a result of all these many changes over time] “it stinks.”
/p