Have you heard of zen of python? If not why don’t you type the below command in the python console.
import this
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!When you press enter few philosophies will come up and these are called the zen of python. In this article, we are going to see what these philosophies tell us exactly.
Beautiful is better than ugly
Well, this statement is self-defining. This is from where the python indentation system must be carved out from. The way you write python code itself makes it beautiful. This was just an example in general you should write code in a well-formatted and simple manner. Mind it there is nothing ugly and beautiful in real life. It the perspective of everyone and it can differ :). And humans are special they are not beautiful or ugly. here goes some of my philosophy.
Explicit is better than implicit
What this means is that if you can define something you should and should not the code to handle it implicitly because it hides information. Your code is as transparent as it can be. It should not have implicit behaviour
Simple is better than complex.
Yes and this will help the next guy to understand it easily. Don’t try to do something in a complex way just because they look cool. Cool is not always beautiful 🙂
The complex is better than complicated
This is an extension of the last zen. Well, it’s really complex to tell what this means, I am also confused here. But what I can think of is that making things complicated for someone to use it. Maybe this thread talks more about it. Complex vs complicated
Flat is better than nested.
The more the nesting more complicated it becomes to understand the code. So write flat code. Also, nesting increases the time complexity of the code. So try to avoid nesting. Nesting does not always increase complexity. if you have a poorly written if-else statement your code will be tougher to understand.
Sparse is better than Dense.
This is somewhat related to a modular code. Don’t write everything at one place. Write things in different modules, so it will be easier to understand what each module accomplishes.
Readability counts
Well, I don’t think I should explain more. But a word to those who things that their code is better just because a normal coder can’t understand this. Maybe you should think about it. Comment properly.
Special cases aren’t special enough to break the rules.
Well, this is special. The zen straight forward says. If you start adding exceptions you will end up in a mess of exceptions. So be vary of them. Everything should be built by keeping general things in mind. There are rules made as in programming concepts. One should never try to override those.
Although practicality beats purity.
Well, there can because when you have to make exceptions to make it usable. These are the cases where you have to break the special case clause.
Errors should never pass silently.
And to add to these. They should be caught as early as possible. Your program should scream if there is an error to save itself.
Unless explicitly silenced
Again a case of last rules. There are cases when you know about the error and you decided to live with it.
In face of ambiguity, resist the temptation to guess.
When you are not clear about something, try to find out the reason instead of guessing the cause. Don’t put everything in try-catch if you are not catching errors properly. One of the basic principles of Golang.
There should be one– and preferably only one –obvious way to do it.
This is confusing. What I think this says is there is one perfect way to do it. And that may be tough to find but you should try to find the most optimized way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Well related to the last one, it may take time to find the best way.
Now is better than never
The seems like a talk on perfection loop. This means that sometimes people spend too much time on design. There should be a proper time to design and implement. Don’t get stuck in a perfection loop.
Although never is often better than right now.
Again referring to the last point. Don’t reduce your time of thinking and design as you may end up deciding on something which is not possible.
If the implementation is hard to explain, it’s a bad idea.
Hard explanation means complex or complicated implementation and as per the existing rules, it is not good.
If the implementation is easy to explain, it may be a good idea.
If it is easy to explain it is a good idea as the design is simple than complex.
Namespaces are one honking great idea — let’s do more of those!
Separate things out, let things work in different namespaces. How this can help is by not interfering in other tasks.
These are my views on what all of the zen means. You can derive your own idea and implement them.
If you like the article please share and subscribe
