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 <[EMAIL PROTECTED]> 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@python.org > http://mail.python.org/mailman/listinfo/tutor > -- Michael Langford Phone: 404-386-0495 Consulting: http://www.RowdyLabs.com
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor