It is the first week of my path towards learning data science and AI to contribute for a better future. I am glad that I have got this opportunity to learn the ‘big thing’ happening across the globe. We have started with the basics of python: mostly used language for data manipulation. Out of all the topics from the Introduction to python till functioning of operators, I liked the Zen of python the most which is collection of 19 ‘principle guidelines’ for writing a program. I am going to talk briefly about them and how I perceived them.
1. Beautiful is better than ugly:
It means that the code should not only be developed with the developer’s point of view but also according to the reader f the code. The readability of the code should be consistent.
2. Explicit is better than implicit:
The code should be clear and transparent as a glass of water. Naming the function based on its functionality is good idea rather than letting the user to guess.
3. Simple is better than complex:
It can’t get any simpler, right? If you can solve a problem using a simple built-in function then you don’t need to write an entire program for it.
4. Complex is better than complicated:
It means that you should not try to over-do a task. You should not try to complicate things just for the sake of simplicity.
5. Flat is better than nested:
How would you feel if you had to open a folder in a folder in a folder to get to the desired file? Annoyed, right? The same goes for python. It’s better to have a Top-layer of module which contains the code rather multiple sub-modules.
6. Sparse is better than dense:
Code which is written which follows standards for spacing and lines are better than the codes which are congested and tough to read.
7. Readability counts:
The readability of a code matters as the code is developed once but read a multiple of times. Understanding the code and its functions should be easy.
8. Special cases aren't special enough to break the rules,
9. Although practicality beats purity:
It means that there are certain rules which are the way they are for a reason and that is to maintain consistency. They aren’t supposed to be altered according to the user but at the same time for the practicality purpose you can bend some rules.
10. Errors should never pass silently,
11. Unless explicitly silenced:
The user should be informed about an error and then corrected rather than automatically correcting the error. This helps the user to understand why the error occurred in the first place. The error can be silenced in case it is quite obvious.
12. In the face of ambiguity, refuse the temptation to guess.
In case, you are unsure about something in the code then it’s better to cross check with multiple arguments rather than guessing it. It can cause a lot of confusing in the long run.
13. There should be one-- and preferably only one --obvious way to do it,
14. Although that way may not be obvious at first unless you're Dutch:
It means that there might be a variety of options for performing a task which provides flexibility but it’s better to go for the most obvious and the least confusing one.
15. Now is better than never,
16. Although never is often better than *right* now:
It’s better to make the module of the code available that works rather than completing the entire project and then submitting. Meanwhile, we should also consider the requirement of the code as a code provided *right now* may become obsolete in no time.
17. If the implementation is hard to explain, it's a bad idea,
18. If the implementation is easy to explain, it may be a good idea:
It can be inferred that a code which is hard to debug for the developers is definitely a bad idea but if the code is easily understood and can be debugged by the programmer then that doesn’t necessarily means that it’s a good idea.
19. Namespaces are one honking great idea -- let's do more of those!
We all have been through this already. We know how great namespaces are. Namespaces help us to use a name multiple times depending upon the scope. This saves us a lot of time and energy that we waste on thinking of a new variable name.