Question: coding style in the book: spaces around operators and between parameters

[VictorNorman]

In my class, I am a stickler for writing beautiful (or as I call it "hospitable") code. One thing I try to emphasize is spacing -- uses spaces to make code as easily readable as possible.

One thing that bugs me about a lot of textbooks is that they write code like they are trying to save disk space, but removing as many spaces from the code as possible. Here is an example, from this textbook:

return Fraction(newnum//common,newden//common)

This line of code is so much more readable with some spaces in it:

return Fraction(newnum // common, newden // common)

Also, putting spaces around operators follows (generally) PEP-8's recommendations on how to write python code.

Similarly, there should be spaces in parameter and argument lists, so that readers can more easily see how many parameters/arguments are being declared/passed:

def init(self,top,bottom):

should be

def init(self, top, bottom): # much more readable.

If I submitted changes to the textbook to make these changes, would they be accepted? It is going to take a bit of work to go through all the code in the book, but I can do it while watching old reruns of StarTrek:TNG on Netflix. But, I don't want to do it if you consider it to be too much of a stylistic thing.

Thanks.

Vic

[bnmnetp]

Well, having authored the paper version of the data structures book, I can say that it is not disk space so much as line space. With the margins and font sizes that publishers impose on you it often turns out to be hard to write good looking code that fits on one line. I distinctly remember the frustration of going back through the example code trying to squish things down to fit on a line without mindlessly breaking up function calls onto multiple lines everywhere.

In fact I'm looking at the listing in the paper book for the line you give as an example and there is not room on that line for four spaces.

With that said, I think it is much less of a concern in an eBook, and I'm in favor of PIP-8 conformity though I'm clearly not a slave to it.

I guess the only caveat to think about her is to make sure that the user does not have to constantly be horizontally scrolling the activecode element to see a line of code. I would rather have a few missing spaces between parameters here and there than for the user to only see 3/4 of the line. Would you agree?

[akulakov]

No, I would not agree. More to the point, PEP8 and python community does not agree -- PEP8 doesn't say anything about squishing things to fit into one line, but it does say spaces need to be added after the comma and surrounding operators: x, y rather than x,y and x / y rather than x/y.

[bnmnetp]

Its fine to be an advocate for PEP8 conformity, but please don't lose site of the big picture and the audience of the textbook. Namely, first year college students who have never written a line of code in their lives.

When our original textbook was written 11 years ago we made the conscious choice to ignore certain PEP8 conventions because we were in a world where we needed to prepare students to move into Java after one or two semesters of Python. The common convention in that world was camelCase. Our book, our decision. In addition I will defend the tradeoff of making things fit onto one line to conform to the space requirements of a paper book. PEP8 is a guideline, not a law. You can disagree with the decisions we made, but you weren't there at the time.

Times have changed. In the next revision, I would follow a lot more of the PEP8 guidelines, I would eliminate getters and setters, I would be better about using whitespace, particularly in an online book. I would do lots of things different and take a much more Pythonic approach today.