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

Aaron Rubin aaron.rubin at 4dtechnology.com
Tue May 19 19:53:33 CEST 2009 

On Tue, May 19, 2009 at 10:14 AM, David Stanek <dstanek at dstanek.com> wrote:

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


See below for code example


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


I gave an example already in the snippet you quoted.


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


Regarding this and the other notion of 5 or 6 being the proper level of
indentation:

class a(object):
    def method1(simulation=False):
        try:
            if simulation:
                for x in range(10):
                    if x>5:
                        try:
                            # here might begin some actual math, with two or
three more levels of logic, interfacing with other libraries such as NumPy,
etc. where you might need specific error handling
        except CustomError:
            # customer error handling

i.e. the logic code *started* at the 7th indentation level.  But I'm sure
you can find plenty of examples where it might be more.


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


or responding to people's posts about character width issues ;)


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


Wing IDE.


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


Lots and lots and lots :)  Started using Python over 10 years ago.  Use it
all day, every day.  Love it :)  Using good OO to me seems to accentuate the
need for greater line widths (point #1) in a large project (i.e. classes
need to be hierarchical in a big project, therefore in order to
disambiguate, more characters are needed to refer to this class)


>
>
> --
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090519/99b4513e/attachment.html>

More information about the Python-ideas mailing list