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 <[EMAIL PROTECTED]> 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 <[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 > > -- 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 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
