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

[MRAB]

Mike Meyer wrote:
> On Tue, 19 May 2009 15:36:35 -0700
> Aaron Rubin <aaron.rubin at 4dtechnology.com> wrote:
> 
>> On Tue, May 19, 2009 at 10:51 AM, Mike Meyer <mwm at mired.org> wrote:
>>
>>> On May 19, 2009, at 12:43, Aaron Rubin <aaron.rubin at 4dtechnology.com>
>>> 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.
> 
With screens in glasses and built-in mini-projectors you'll be able to
have wide displays again even on PDAs. :-)