Both the design and the culture of Python are somewhat unique in their focus on readability and comprehensibility when writing code. One of the people responsible for this philosophy is the creator of python, Guido van Rossum. One of his key insights is that code is read more than it is written. “You primarily write your code to communicate with other coders and, to a lesser extent, to impose your will on the computer.” This idea has driven the emphasis on readability when writing python code (and code in general).
If Guido van Rossum is the father of Python, then perhaps Tim Peters is the language’s uncle. He helped shape the design of the language in its infancy and has been a staple in the python community nearly since its inception. He has made many contributions to both the language itself and PEPs (Python Enhancement Proposals). One of his better-known contributions to the community is “The Zen of Python”.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
These principles were intended as guidelines when creating the language itself. They were meant to be used the creation of python itself, to make the language easy to read and grasp and understand. But for many, they have become a de-facto style guide as well. And it makes sense - the principles that would make a language easy to read and understand also apply to making a product or a codebase that is easy to read and understand.
If you are writing code that will be maintained and read and edited and expanded upon in the future, these principles likely apply. This is doubly true if someone other than you will be doing the maintenance. The good news is that they’re easy to use. They’re intuitive and easy to understand. In fact, you’ve probably been applying some of them in your code already, even if you’ve never seen them written down.
Now, I’m not the first person to talk about the importance of writing clean, readable code. Nor am I unique in suggesting that the zen of python might apply to the actual code you write. But adhering to these principles (or any set of style guidelines you choose to employ) becomes far more difficult when you are maintaining code.
Often you are adding a quick feature or squashing a small bug, and the quickest, easiest way to do that is by wedging a few lines of code into the middle of a function. And even if you are putting more thought into the process, it’s often harder to keep style guidelines in mind when you’re maintaining or editing existing code.
Following style guidelines necessitates a more deliberate approach. There are a couple things you can keep in mind when maintaining or updating a section of code.
What decisions is this code making? What is the decision tree currently?
How would the decision tree change after the changes I need to make?
Is this modified decision tree more complicated or confusing than it needs to be?
Is there a different decision tree that would make more sense with these changes?
Asking yourself these questions should help you determine where your changes should be made and whether you should refactor your code.