PEP 8, beautiful code, and the tyranny of guidelines.
I’m no Python developer, but I learned a great deal from Raymond Hettinger’s Pycon 2015 presentation, Beyond PEP 8: Best practices for beautiful intelligible code. It could as well have been called ‘the danger of standards’:
For those not in the know (and I wasn’t), PEP 8 is a set of style guidelines for writing presentable Python code. Hettinger takes the view that it’s good, but not perfect. But even so, its mere existence and misuse is enough to cause all kinds of problems.
Bad rules and minor atrocities
The first problem with any set of guidelines is the most obvious. No set of guidelines short enough to write down will get it right in every situation. The weakest part of PEP 8 is its rule on line lengths. 79 characters is just too short for many purposes, especially with indentation, and especially when writing debugging scripts.
But once the rules exist, and your code is judged against them, you better follow them. So how will you get your code down to 79 characters per line? There are plenty of options, all PEP 8 compliant and they all make the code worse:
- Use shorter variable names.
- Break the line in some arbitrary place.
- Switch to two-space indentation instead of four-space.
Hettinger calls these ‘minor atrocities’ — expedient little sins that make the world worse. There are two problems at work here. First, 79 characters is just not enough for a lot of purposes. These days, 90 characters might be better.
But beyond that, any absolute number is dangerous. Developers need to remember that lines above a certain length are pushing it (whether 80 or 90 characters). But they should know that sometimes a good long line is better than 2 bad short ones.
As George Orwell said about his own guidelines: break any of them sooner than doing anything outright barbarous.
Getting PEP 8'ed
Once a standard exists, there’s a great temptation to impose that standard on other people’s code arbitrarily. You might even believe you’re doing the world a favor.
The PEP 8 standards warn against this with a quote from Ralph Waldo Emmerson: “A foolish consistency is the hobgoblin of little minds”. But that doesn’t stop eager PEP 8ers diving in and complyifying other developers’ code. Once we know how to do something — and we believe it’s useful and productive — we’ll be tempted to jump in and do it wherever we can. Thus once somebody knows how, they can’t help but perpetrate PEP 8.
With any guideline: follow it yourself sooner than impose it on others.
Missing the gorilla
But by far the biggest danger of guidelines is they can distract us from what really matters. We can pay great attention to following the guidelines and miss the most important things.
If the rules of PEP 8, or any guideline, become our criteria then we limit our judgment — our perception — to the issues covered by the guideline. As an example Hettinger PEP 8ifies a chunk of Python code, making substantial improvements to its readability. But not one person in the audience notices the real issue: this is not really good Python code, it’s a Java approach copied into Python. Once that issue is seen, it’s addressed… and the code quality and readability is transformed, to the point where even I can understand it (and can also understand the appeal of Python, because it uses Python’s unique features).
Being Pythonic
Behind all this is a simple principle. Good Python code is Good. Python. Code. It isn’t good Java code or good C code. It has to be judged against the standard of what good Python looks like.
This is perhaps the key to quality Python and quality everything. Quality is not in adherence to a long list of guidelines. It comes from having a clear idea of what good is, and bringing your work as close to that idea/ideal as you can.
Finishing
One other thing I learned from the video: how to end a talk if you overrun. Raymond handles the MC with such grace, and you’ll have to watch the video to the end to learn from that.
