On Tue, 19 May 2009 15:36:35 -0700 Aaron Rubin wrote:

On Tue, May 19, 2009 at 10:51 AM, Mike Meyer wrote:

...

On May 19, 2009, at 12:43, Aaron Rubin wrote:

I realize that this is a religious debate which has gone on for many centuries. I appeal to the scientific aspects, with a distinct avoidance of preference and emotion. Preference might be easily explained by "right brain" vs "left brain" preference, but either way, it is merely a preference and I want to stick to facts. Here is a list I have compiled of facts which support a wider than 80 character line width standard (in Python, specifically). Please add to them, subtract from them, or add to the other side of the debate, but please avoid the usage of the word "readable" (which implies preference), unless you are referring to a scientific study of readability, which would be great.

Most of you points don't stand up under inestigation. Of course, negating them doesn't support am 80 character limit by itself.

1) Python is three things which the standard was not designed for: One: Object Oriented. Two: Not Hungarian notation Three: Mandatorily uses *whitespace* as its defintion for code blocks. Let me explain each one in a bit more detail: Object Oriented: Because it is not functional-style programming, but instead OO, you have to give defintion as to what object type you are using before using it. This makes definitions and usage longer than in functional programming (when 80 character widths were invented). PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber is an example (and not an extreme one) of a class (55 characters already) in a rather large code base.

This type of reference is considered by some to be bad style. See the "Law of Demeter" for more information.

The Law of Demeter applies to objects referenced second-hand. The class name given is an example of a hierarchy of modules, not one class reaching through a second class to get at the class members it uses.

In python, modules *are* objects, so this is still a case of one object reaching through a second object to get at members of that object. More to the point, Python allows you to use "from <module> import <names>", "import <name> as ..." and even "from <module> import <name> as ...", all of which provide much saner ways of dealing with deep trees of modules.

...

Not Hungarian: Not only is Python not Hungarian (in general), but the PEP-8 specifically tells us to use longer, more descriptive variable names. hasInstrumentControllerPhaseDither is an example. Many variables are 15-20 characters and oftentimes longer. This appears to be false. A quick check of the standard library finds between 1 and 2 percent of variable references to have fewer than 15 characters, rising to 8 percent of unique names. This hardly qualified as many. do you mean greater than 15 characters? If not, then I don't see your point. At any rate, 8 percent of unique names seems statistically relevant. 8 percent of how many? If the number is 100,000, then I would say that 8,000 variable names qualifies as "many".

Yes, I meant greater. And if you make your program small enough, 8,000 will be many. Then again, nearly any number qualifies as "many" if you're innumerate. The point is that if you want to use existing code to provide a reason for changing things, you should be making measurements of an existing code base rather than making vague claims about how common such things are. Since PEP 8 is really only enforced for the standard library, that's a good place to start.

...

Whitespace: Python is very unique in that it *uses* whitespace for code blocking. It turns out to be very useful, since it visually cues the reader where code blocks begin and end by mandate. This creates many situations where code *starts* at the 10th indentation (40 characters in our standard, 80 characters in some Python standards). This also appears to be false - the standard library has fewer than 200 lines out of over 80,000 that start that deep. "Rarely" would seem to be more accurate than "many". 200 lines might qualify as many. Regardless, there are quite a number of lines which do. Let's not argue over the meaning of "many". As long as "some" exist, the point remains.

Yes, but the quantity matters. Changing things will result in pain for some users - that's part of why they don't change. If you want to use a problem with the way things are that causes pain to justify making a change, you need to show that it occurs frequently enough that the pain it's causing outweighs the pain that would be caused by the alternative and adopting the change.

...

3) Writing new code in 80 character line widths takes more time. If I have to worry about hitting this width, I have to de-concentrate my efforts of writing logical code and concentrate instead on how exactly to format this line of code (where to break it, etc....there are a number of rules attached to wrapping lines of code). Then I have to re-concentrate on the actual task at hand. Alternatively, I can code it up without worrying, then when convenient, take some time to reformat to 80 character width. Either way, more time.

On the other side, the Oulipo school of writing believes that writing with apparently arbitrary constraints improves the results. I find that if I'm running into the 80 character limit with any frequency, it's because my code is poorly structured and in need of a reworking. That can definitely be a symptom of bad code. Doesn't mean it's the only reason for it, however.

The number of reasons is irrelevant: you claim that writing to an 80-character limit slows you down, others claim that it causes them to write better code, so this matter also calls for more investigation. Are there studies that deal with either otherwise apocryphal claim? In particular, how many people are affected by each.

...

You really need better justification - studies of program comprehension, not English reading speed, code bases that support your claims about written code, etc. I would love to see these studies done, but at this time I cannot find them.

That's sort of the point. You're making claims with few or no quantitative values to attach to them. I.e. "many variables use long names, and you can't get a lot of those on a line." A few minutes with grep & wc on the standard library suggest to me that this isn't the case. My "study" was admittedly unscientific and inaccurate - back of the envelope type stuff, but it's still more rigorous than what you started with. If you want to put your arguments on a scientific basis, you'll do some analysis of a real code base to provide quantities to back things up. One final addition - while it's true that desktop monitors are getting wider and cheaper, it's also true that we're moving to a world where people regularly work on things that aren't desktops. Laptops are getting cheaper and *smaller* as well as larger, and there are good reasons for not wanting a 17" - or even a 15" - laptop, which means you're back to screens the size of the old glass TTYs (which I fondly remember as light blue on dark blue, at least in the last iteration). Netbooks take us even smaller - and people have been putting development systems on PDAs for over a decade. So while developers now may have access to systems with multiple windows that are 120 or more characters wide, they also now use devices that have to stretch to their limits to display 80 columns across. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On the other side, the Oulipo school of writing believes that writing with apparently arbitrary constraints improves the results. ??? How can you assert such a non-pertinent (and wrong) statement (in regard to the point beeing discussed)? Oulipo games are about helping *creativity*. A set of strict constraints helps the poet be creative -- or rather they let whatever unconsciounsly creates "popping" good mattery into conscious poetic minds. Denis

spir wrote:

On the other side, the Oulipo school of writing believes that writing with apparently arbitrary constraints improves the results.

Oulipo games are about helping *creativity*.

The best explanation I've seen for this phenomenon is that it works by forcing you to avoid cliches. For example, if you have to fit your words into a fixed meter, you can't just use the first phrasing that comes into your head. You have to hunt around for alternative words that fit the pattern, and in the process you most likely come up with something original and surprising. I don't think this applies in the same way when you're writing a program. The goal there is *not* to be original and surprising -- if anything it's the opposite! You want to convey the meaning of the code to the reader as clearly as possible, and if it uses an idiom that the reader has seen before and can instantly recognise, then so much the better. -- Greg

Scott Dial wrote:

Given the large body of code that already follows PEP8 (and other style guides for other languages that commonly use an 80-character boundary), it is a common constraint which yields many common idioms (such as placing list items on separate lines with similar indention).

I still don't think it's the same thing. Limiting lines to 80 chars or thereabouts is not an *arbitrary* constraint. There are intrinsic merits to it, e.g. people find very long lines hard to read, you can fit multiple windows side by side, etc. On the other hand, there's nothing inherently virtuous about writing in iambic pentameter or avoiding the use of the letter "e". The only merit of such constraints is that they push you *away* from a very small area of badness (i.e. cliches) and out into a much bigger area of non-badness (any non-cliched way of saying the same thing). 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. -- Greg

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.