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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20080429/ca64da84/attachment-0001.htm>