[Tutor] Python Best Practice/Style Guide question

[W W]

Even with monospace, I can't really see it being that helpful, after all, in:

x = 3
y = 5
foobar_fun = 20

3 and 5 are in no way related, x and 3 are. However, sometimes I break
them up into more beautiful chunks:

x = 3
y = 5

foobar_fun = 20

sometimes it's more helpful that way.

just my 2.5c
-Wayne

On Tue, Apr 29, 2008 at 1:01 PM, Michael Langford
<mlangford.cs03 at gtalumni.org> wrote:
> This, like many style guidelines, is not something that necessary has an
> irrefutable reason. Sort of like driving on the left or right side of the
> road, it is pretty much custom.
>
> You'll get use to coding like that after a short time if you start. If you
> don't, nothing bad will happen to you, just it will look strange to a large
> number of people. For instance, while if( 3 == a) is a much safer way to
> write a C if statement than if( a == 3 ), I still use the former because it
> is a lot easier on the brains of people I work with (but use lint to catch
> the infamous if( a=3 ) ).
>
> Steve McConnell's Code Complete has an excellent chapter on this and other
> "whitespace code art" that basically boils down to while it seems like it
> adds, it takes a lot of time to maintain, so you're probably not coming out
> ahead in the long run.
>
>            --Michael
>
>
>
> On Tue, Apr 29, 2008 at 12:22 PM, Scott SA <pydev at rscorp.ab.ca> wrote:
> > Per the interesting read at <http://www.python.org/dev/peps/pep-0008/>
> >
> > Can anyone explain the rationale behind this:
> >
> >    - More than one space around an assignment (or other) operator to
> >      align it with another.
> >
> >      Yes:
> >
> >          x = 1
> >          y = 2
> >          long_variable = 3
> >
> >      No:
> >
> >          x             = 1
> >          y             = 2
> >          long_variable = 3
> >
> > The example is rather simplistic and I find the latter form much easier to
> read when there is more than three or four assignments. Furthermore, I don't
> like the use of 'x' and 'y' style variables for anything but classical
> references and concise loops favoring 'chart_x' and 'chart_y' (I have a
> crappy memory, more descriptive names help me, and those reading my code,
> keep track of what I'm doing).
> >
> > I _do_ see that in this example, it could be hard to follow which value is
> assigned to its respective name, but considering this _slightly_ less
> simplistic (though flawed) example:
> >
> >    string_item = some_method(with_argument)
> >    y = 2
> >    long_variable = antoher_method(with, multiple, arguments)
> >    another_string_item = some_method(with, more, arguments)
> >
> > Is easier to read (for me) as follows:
> >
> >    string_item        = some_method(with_argument)
> >    y                  = 2
> >    long_variable      = antoher_method(with, multiple, arguments)
> >    another_assignment = some_method(with, more, arguments)
> >
> > _Yes_ the order can be changed, but there are reasons why it might be
> inapropriate to reorder i.e. dependencies.
> >
> > TIA,
> >
> > Scott
> >
> > PS. There is a good best-practice link here too:
> >    <http://www.fantascienza.net/leonardo/ar/python_best_practices.html>
> > _______________________________________________
> > Tutor maillist  -  Tutor at python.org
> > http://mail.python.org/mailman/listinfo/tutor
> >
>
>
>
> --
> Michael Langford
> Phone: 404-386-0495
> Consulting: http://www.RowdyLabs.com
> _______________________________________________
>  Tutor maillist  -  Tutor at python.org
>  http://mail.python.org/mailman/listinfo/tutor
>
>



-- 
To be considered stupid and to be told so is more painful than being
called gluttonous, mendacious, violent, lascivious, lazy, cowardly:
every weakness, every vice, has found its defenders, its rhetoric, its
ennoblement and exaltation, but stupidity hasn't. - Primo Levi