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

[David Stanek]

I'll bite.

On Tue, May 19, 2009 at 12:43 PM, Aaron Rubin
<aaron.rubin at 4dtechnology.com> wrote:
> 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.

If you are using more than 5 or 6 levels of indentation you may be
doing something wrong. I would guess that your methods are too complex
or maybe you are violating the SRP.

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

I'd like to see an example of your variable names. I don't use
hungarian notation and my name are usually under 10 characters.

>   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?)

I'd like to see an example of where using 10 levels of indentation is
good. I'll bet that it's not easy to test.

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

I partially think you're right. Although I have the same problem with
long lines that have multiple levels of parens.

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

I don't really have this issue. The few seconds a day that I waste
formatting code are nothing near the time I waste on YouTube :-)

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

I would actually like to see tools changed to make this better. Maybe
similar to the way unified diff shows a few lines of context.

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

Sure I guess. I am typing this on my EEE 900 which won't like much
more than 90 chars. But even at work I put multiple 80 char wide
windows side by side.

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

Agreed. Use Vim with 80 characters and you will rock out code like
never before. I hear Emacs is good too. What are you currently using.

> 7) Python is designed to be written more like English than other programming
> languages.

That's news to me.

On another note when we hire new developers I often hear this
argument. Once they start coding in Python and using good OO/TDD
techniques they realize that it really doesn't matter. Out of
curiosity how much Python coding do you do?

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek