The Zen of Python is a set of principles defined from the American software engineer Tim Peter in 1999. Those 19 principles are recommendations for developers and engineers to keep continuity in coding.
- 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!
The Zen of Python is so fames and important that you can use a little Easter egg in almost every Python environment to show the rules. Type
import this in the console and execute the command.
Even tho it is called „Zen of Python“ the most mentioned principles can be applied in almost every programming language.
If you read the principles, you will notice that some of them are reasonable and useful and some are unclear und confusing. Some even seem to be not really serious and meant as a joke. For example the principle number 14:
„Although that way may not be obvious at first unless you’re Dutch.“
This is a reference to the Dutch programer Guido van Rossum, who invented and created Python. Tim Peter left even space for a 20th principle in hope that Guido von Rossum would complete the list – but he never did. Programer have sometimes a strange humor.
But most of the principles are meant seriously and should be implemented.
The 1st one „Beautiful is better than ugly.“ is asking programers and engineers to keep their code understandable. Most try to be efficient and don’t pay attention to how their code looks like. They only want it to work properly. Some one else will have a hard time to understand it.
The rule number 3 „Simple is better than complex.“ and 4 „Complex is better than complicated.„compete each other. First we are reminded that there is always a simple way to a solution. Then we are reminded that it is not recommendable to use simple solutions for complex problems. It may be possible but you will end up with a complicated solution. So it is better to find a complex solution for a complex problem, than a complicated solution, consisting of simple solutions, for a complex problem.
Every principle has its meaning and and its reason of being. But as already mentioned they are no rules everybody is forced to follow. But they make our life way easier and help to us to work together, have a base to communicate on and tire us together as a community.