THE ZEN OF PYTHON
The Zen of Python was written by Software engineer Tim Peters. He
posted it on the python mailing list in 1999.
He wrote nineteen (19) python aphorism to help python users write a clean codes. Tim left the twentieth spot on his nineteen guiding principles to be filled by Guido Van Rossum, the author of Python programming language.
Did Van Rossum fill the spot? No, he didn't.
Tim's Zen of python was included as an entry number 20 in the language's official Python Enhancement Proposals and was released into the public domain.
It is included in your python IDE. You can view it by typing:
>>> import this
The Zen of Python says:
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 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 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!
REVIEW
The way I see it is that the Zen of python actually doesn't talk about coding/programming but it talks more about life. It advises you just like the ten commandments. (If you're atheist, I'm sorry)
Beautiful is better than ugly
As a programmer, writing codes and making it run isn't only the job to do. Writing a readable and neat code is an art appreciated by other programmers which makes them understand every bit preventing unnecessary headaches.
Explicit is better than implicit
It is better to make your code more explicit(clear and direct) as this will make your codes more readable.
Simple is better than complex
Why write a complex while you can build a short or a simple one. Some programmers think the more complex your code is, the more other programmers will give you respect. This, I think, is a lie.
def recursion_reverse(a):
if (len(a)==1):
return a
else:
return recursion_reverse(a[1:]) + a[0]
main_sting = "XYZ"
print("reversed string: ", recursion_reverse(main_string))
You can simply write a few lines of code for the above lengthy code.
new_sting = "WXYZ"
reversed_string = new_sting[::-1]
Complex is better than complicated
A problem might require a complex technique to solve but it shouldn't be complicated.
Probably if the problem you want to solve calls for multiple interconnected parts, forcing a simple solution will invite stress and confusion.
Flat is better than nested
Programmers like to create sub-models for each functionality.
for instance, If i build a module, "spam" and adds sub-model "foo" and in it I add "baz".
Accessing another sub-package from baz will be:
from spam.foo.baz import eggs
Sparse is better than dense
We at times want to do everything in just a single line of code. The can run might run very well but probably it will have issue with readability. Can other programmers understand just glancing through?
You can break it into parts to help other programmers help you without any difficulty.
Readability counts
When you get stuck with your codes, probably you'd result to friends or say StackOverflow. On StackOverflow you'd choose the most readable codes not the complicated ones.
Readability also saves time.
Special cases aren't special enough to break the rules
Your codes follow the best practices where necessary. Van Rossum took the design and functionality serious when building python.
For example;
>>> addition = 0.1 + 0.8
addition = 0.9
False
The above would've return True if it was to be Java. However, python wont python won't break rules of floating-point numbers for primitive data types.
Although practicality beats purity
This procedure implies there might be an exception to the given set of rules.
Errors should never pass silently
Avoiding silent errors lead to bugs. Hence using 'try - except' statement becomes very helpful as it prevents silent errors
Unless explicitly silenced
When errors are often not serious enough to require an immediate attention, you'd want to explicitly ignore these warnings when running the code.
In the face of ambiguity, refuse to the temptation to guess
Ambiguous codes can lead to hours or days trying to figure out where things are went wrong. Explicit error handling avoids ambiguity in your codes.
You don't need to guess when something goes wrong with your codes. Most Python IDE's gives hint as to where the problem can be found. If you fall short of ideas, googling your problem is very helpful.
There should be one - and preferably only one - obvious way to do it
This is somehow an insincere way of addressing Perl creator Larry Wall's exhortation that "There's more than one way to do it"
There are a lot of ways on how to go about programming. No matter which implementation you choose, try to be stick with the same choice throughout your code base. (Thus choosing "only one" way to do it). T
This makes code to be concise.
Although that way might not be obvious at first unless you're Dutch
This procedure/guideline says the rule of the language will not be easy to recall unless you're van Rossum. A joke referring to BFDL
Now is better than never
This guideline suggests it is better to go ahead and try creating something now than it is to simply sit around and guess whether or not it might be a good idea
Although never is often better than right now
This guideline and the one above resemble and contradict each other.
But this guideline throws more light on avoiding poor implementation (moving ahead with an ideology that hasn't been well thought out)
If the implementation is hard to explain, it's a bad idea
If you find it really hard explaining your codes to peers or other programmers, then something is wrong with your codes.
If the implementation is easy to explain, it may be a good idea
As a programmer, you'd be mostly contacted by people with or without interest in programming. It is very important to be able to explain plainly what your codes does.
If explaining to non-programmers and you'd require the use of some terminologies, then you might want to rethink of your implementation.
Namespaces are one of honking great idea - let's do more of those
Having a system to have a unique name for each and every object is called a namespace. The nesting of one or many modules inside the other is illustrates the use of namespaces.
Conclusion
Python is really cool and amazing that's why a lot of programmers work with it. Tim Peters made these guidelines to motivate every programmer on their 'quest to greatness'
Enjoy.
Thank you.
REFERENCES
4. Ideas from The council of Monarchs.
Comments
Post a Comment