Re: [Python-ideas] 80 character line width vs. something wider

On Tue, May 19, 2009 at 10:51 AM, Mike Meyer <mwm@mired.org> wrote:
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.
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".
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.
That can definitely be a symptom of bad code. Doesn't mean it's the only reason for it, however.
I would love to see these studies done, but at this time I cannot find them. The closest I could come (and I disclaimed that it was only a loose connection) was the study I referenced.
<mike

On Tue, 19 May 2009 15:36:35 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
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.
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.
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.
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.
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, <mike -- Mike Meyer <mwm@mired.org> 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 <denis.spir@free.fr> wrote:
Do you think that writing code is an act that does not involve creativity? Writing with constraints to improve creativity applies to any kind of writing, not just poetry. I heard about the idea in my creative writing class; I've never heard of Oulipo before. It also has already been invoked in this thread with respect to writing programs: constrained to 80 characters, you are encouraged to refactor the code, thereby producing superior code. --David

spir wrote:
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

Greg Ewing wrote:
And therein, you have defeated your own argument. 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). The readers wished hard For the thread to die quickly Sadly it goes on -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

Scott Dial wrote:
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:
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?
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.

On Tue, 19 May 2009 15:36:35 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
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.
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.
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.
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.
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, <mike -- Mike Meyer <mwm@mired.org> 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 <denis.spir@free.fr> wrote:
Do you think that writing code is an act that does not involve creativity? Writing with constraints to improve creativity applies to any kind of writing, not just poetry. I heard about the idea in my creative writing class; I've never heard of Oulipo before. It also has already been invoked in this thread with respect to writing programs: constrained to 80 characters, you are encouraged to refactor the code, thereby producing superior code. --David

spir wrote:
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

Greg Ewing wrote:
And therein, you have defeated your own argument. 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). The readers wished hard For the thread to die quickly Sadly it goes on -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

Scott Dial wrote:
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:
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?
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.
participants (9)
-
Aaron Rubin
-
Greg Ewing
-
Mike Meyer
-
MRAB
-
R. David Murray
-
Raymond Hettinger
-
Scott Dial
-
spir
-
Stephen J. Turnbull