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

[Aaron Rubin]

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.
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.
  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.  How many of these variables can you fit
into a line if we are limited to 80?
  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).  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.  Many libraries do adhere to 80
character line width as well.  However, a library which is written in 80
characters still fits the paradigm of those which are wider and therefore
backward compliant.  In other words, if your tools are geared toward 80
character line widths and you are now looking at a wider width, things
become quite difficult.  The other way around is fine.

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.

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)

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.

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.

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
they did not try 115, 135, etc. and that they found their maximum data point
at the farthest edge of their study.  One can conclude that they probably
should have gone even further to determine where (if ever) it tapers off.
 This study focuses on reading English, not on reading code.  But given the
first sentence of this point, it should at least loosely correlate.  At any
rate, it's an attempt at something scientific on the issue.

Thanks for the time spent reading this long-ish post.  Thanks for your
feedback if you provide it.

 - Aaron

Aaron Rubin
Software Engineering Manager
4D Technology
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090519/75b44f23/attachment.html>