Zen of Python

>>> import this
The Zen of Python, by Tim Peters

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.
Readability counts.
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!

• Some guiding principles ease maintenance.
• We spend a lot more time maintaining code than writing them.
• This involves a lot of reading than writing of code.
• Some of these principles apply more to the approach we take than to the actual code we write.

• clean code.
• well arranged codebase
• pleasing to the eye

• Hidden magic is very difficult to debug.
• Examples: implicit arguments, catch-all imports

• Simple problems warrant simple solutions.
• Complex problems require complex solutions.
• Unnecessarily complicating things does no one any favour.

For example, approaches that usually complicate a problem:

• trying to prematurely optimize.
• trying to handle obscure edge-cases before solving the core problem properly.

• Applies to modules and their imports.
• Also applies to the level of nesting of code in python.

For example, making sense of a for-block inside a try-block an if-block inside a function poses a lot of problems.

• writing tests becomes difficult because of the number branches
• debuging and stepping through code is also immensely difficult.

• We read code more often than we write be it to maintain or extend functionality.
• It’s difficult to get collaborators for an unreadable codebase.
• A few weeks of inactivity our own code alien to us.

• Don’t break the rules unless there is a disaster at the door step.
• eg: its not a good practice to manually deploy, unless you are in firefighting mode and company is bleeding money.
• another example, local convention takes precedence over general formatting rules.

• Make your programs communicate their greviances to you.
• Programs should not be giving you the silent treatment like some spouses. Make both of them talk.
• testimony: I once dealt with a codebase having multiple nested try-except-pass statements.

• Mulitple ways to achive the same goal confuse beginners. Ask a teenager choosing path to success.

• If it has to be done, delaying it is a bad idea.
• The dead projects and branches will testify to mulling a requirement before beginning to code.

• A module / project / function that your colleagues cannot understand will become your shackles.

• All the Software Engineering course had to teach was: organize it well.

Anuvrat Parashar http://anuvrat.in