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

[Aaron Rubin]

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.


>   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".


>   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.


>
> Even in normal "great design" mode (which takes more time again), you can't
> help it....your code starts at the 6th indentation level often.  (28
> characters, more than 30% of 80 characters already gone.  Now how many
> variables or class names can you fit?)
>   Whitespace (2):  Because Python uses whitespace as its sole method of
> code blocking and because this is the visual cue for code blocks, wrapping
> lines obfuscates this and makes the reader think about whether this
> whitespace was there for a code block, or a line-wrap.  Thinking about
> intention of code slows us down.
>
> 2) Many of the libraries that are widely used do not adhere to the 80
> character width line standard.  wxPython, NumPy and Boa Constructor are a
> few, but I'm sure there are many, many more.
>
>
> Which just goes to show that you don't hve to be constrained by the PEP if
> you don't want to. Notvthat doing so is a good idea.
>
> 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.


>
> 4) Code searching.  IDEs have powerful searching features.  They list all
> the lines of a file (or files) which match the string you are searching for.
>  If things are in one line, this search is meaningful and you can read it
> like you can code.  If a line of code actually spans two (or more) lines
> of code, the search is no longer contextually useful and you have to click
> on each item to see what's actually going on.  This feature is used heavily
> in many environments (especially large code bases) to save time, but time is
> either lost finding the actual context of a found string, or the search tool
> is avoided altogether because it does not provide meaningful results (i.e. a
> predictive waste of time)
>
>
> In that case, you need a better IDE; it should either show more context,
> allow multiline searches, or both. Both of these things will help even if
> you never wrap your lines.
>
> 5) Monitors are getting bigger, wider, cheaper.  This allows us to have two
> files, side-by-side on a screen that are *both* 120 character width (or
> even wider), without changing font sizes.
>
>
> Printers aren't.
>
> 6) Tools are cheap.  Time isn't.  Get a second monitor, get a more powerful
> editor, do whatever it takes to save time.  If viewing more information at
> one time is important, then we should try to make that possible with
> technology, not time.
>
>
> This point seems to be at best neutral to where or if you wrap lines.  A
> good IDE will wrap the display and indicate it did so.
>
> 7) Python is designed to be written more like English than other
> programming languages.  English is written horizontally, not vertically.  In
> furtherance to an attempt to make "readability" an objective argument, here
> is a scientific study which finds that greater character width lines
> improve readability:  <http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp>
> http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp.
> To summarize, the study found that of the choices of 35, 55, 75 and 95
> character lengths, 95 was able to be read the fastest.
>
>
> Please note that the study *started* by pointing out that other studies
> existed which found the best line length to be anywhere from 35 to 85
> characters, and gave no reason for trusting their results rather than the
> earlier studies. I would claim that all studies that looked at written
> languages - as opposed to programs - were inapplicable. They almost
> certainly used variable width fonts and a left justification (if not both),
> either of which has more effect on readability than line length.
>
> Thanks for the time spent reading this long-ish post.  Thanks for your
> feedback if you provide it.
>
>
> 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.
 The closest I could come (and I disclaimed that it was only a loose
connection) was the study I referenced.


>
>       <mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090519/3ffd9d4c/attachment.html>