Greg Ewing writes:
I don't think you can do the same thing with programming. You can't get a good program just by avoiding bad things, you have to actively aim for the good things.
You think you can get a good poem simply by avoiding bad things? Surely not! There are still an infinite number of ways to write a bad haiku, despite the extreme style constraint, and great haiku writers remain rare. I think the analogy programming to poetry is quite strong. And in a discussion of Python, there should be no question that an arbitrary line-length limitation aims at the good things: "flat is better than nested". The question here is, how accurate is that aim? Does it too often hit our feet instead?
From the examples presented here (both actual and contrived!) by the *opponents* of line-length limitation, it seems to me that being strict about an 80-character limit is not "a foolish consistency", but rather a quite cheap and accurate way to identify flat-is-better-than- nested violations. The time spent *in implementing Python and the stdlib* on avoiding and fixing those is time very well spent, IMO. Other projects *should* make their own judgments.
There are two specific usages that I think may deserve exceptions, because they don't involve flat-is-better-than-nested violations. The first is line-terminating comments. These are *good* style IMHO in cases where a particular statement requires glossing. I don't see how to reformat those to meet line-length limitations except by moving them above the glossed statement, which is ambiguous (how many statements are in the "scope" of the comment?) and, worse, interrupts the flow of control when reading the code. The second is strings for presentation in a line-oriented terminal context, such as error messages and docstrings. I like these to be about 65-70 characters wide, but there are some cases (eg, first lines of docstrings) where that is regularly desirable to violate. Here in practice I use Ben Finney's "indent one extra level" and Jim Jewett's "escape newline and start string at left margin" techniques, but I'm not 100% satisfied with them.