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!
—Tim Peters
This series of apparently senseless phrases are what Tim Peters considered the Zen of Python. For me it was quite hard to understand at the beggining, but then I found this page which helped me a lot to understand what this Zen was about.
They depict in weird poetic way the customs that one should follow when coding, in this case in Python but most of them apply to any programming language, so that your code is not only efficient, but also easy to read and understand by even other people beside you.
And well the page that I have posted above gives some good examples to the phrases that are stated in the Zen of python. But if you don’t want to look to an example of every line well I will give you a summary.
When we say that beautifull is better than ugly is a sugestion as to ident the program, no more horrible one long lines that means too much to understand them. Whenever we do, call or whatever something we should show clearly what we have done, so there are the less amount of guesses about our code there can be.
Whenever you have to choose between a bunch of easy code that just screws people’s minds you better choose some complicated but yet fewer functions or chunks of code that can help one follow the thread of your code. And of course avoid those long chains of nested loops or conditionals, they just scream: skip me!!
The other thing that we have to take care of is about making our code too complex just for especial cases, many times we can just point at them by treating errors instead of making our code very difficult to comprehend; trying to not sacrifice too much of its functionality in the process.
We should always try to solve the things the simpliest way we can, a way to figure out if we are doing it right is trying to explain what we have done, if we can’t; then we have a problem.
And for last I don’t know if I have got it right, but I guess it’s abaout using variables to store the values of large statements, and use appropiate names for them, not names that don’t have much sense or even you can’t remmember.
This is my #Mastery8 of my #TC1014
