anandtripathi5/brief_explanation_of_zen_of_python.md

## brief_explanation_of_zen_of_python.md

      
    Raw
  

              brief_explanation_of_zen_of_python.md
            
          
    The Zen of Python is a collection of 20 software principles that influence the design of Python Programming Language, only 19 of which were written down around June 1999 by Tim Peters. You can find the list of Zen of Python in any python interpreter just fire a command - import this


Beautiful is better than ugly.


To better understand this suppose the editor is your canvas and your code is your art, then how much effort you will put in so that someone will call you an artist. According to Somya Ghosh(Random Quora answer) Rather than using && or|| as logical operators, consider using and || or, if it works && is readable to you.
    if ( a && b == 0 || s == 'yes')

Versus
    if a and b == 0 or s == 'yes': 


Explicit is better than implicit.


For this don't compare your code with art, write your code in such a way that every stakeholder will able to understand what is going in those lines and can guess what the function will do by its name only.  Let your code be readable by a stranger who knows nothing about you or your program.
   import os
   print os.getcwd()

instead of this
   from os import *
   print getcwd()


Simple is better than Complex.


Steve Jobs stated once that “simple can be harder than complex”. And that's true. Requires a lot of hard work to get your thinking clean, to come up with a simple solution. But a simple solution is always better than a complex one. Simple communicate better. Simple creates an instant connection. Simplicity is something you can apply in everything in your life – not only programming.


Complex is better than complicated.


The Zen says: It is okay to build very complex applications, as long as the need for it is reasonable. Let's take an example
   counter = 0
   while counter < 5:
       print counter
       counter += 1


The code is very easy to understand. It is not complex. However, it is complicated. You do not need to manually perform most of the steps above.
   for i in xrange(5):
       print i


This code is more complex than the above example. But: knowing the documentation of xrange you can understand it by a single glance. Many steps are hidden behind an easy-to-use interface.


Flat is better than nested.


According to the best explanation ever, flat is “… typically easier and faster to parse, and should be preferred … where you need nested data structures, prefer shallow rather than deeply nested”.


Sparse is better than dense.


In simple words don't try to stick too much code on one line.
    if i>0: return sqrt(i)
    elif i==0: return 0
    else: return 1j * sqrt(-i)

Versus
    if i > 0:
        return sqrt(i)
    elif i == 0:
        return 0
    else:
        return 1j * sqrt(-i)


Readability counts.


It's like the rule of thumb, every rule revolves around this principle. Let's compare C and python for this.
   #include <stdio.h>
   int main(void)
   {
       printf("Hello, world!\n");
       return(0);
   }

Versus
   print "Hello world!"


Special cases aren’t special enough to break the rules.


Best to explain this, PEP8 guideline quotes that
In particular: do not break backwards compatibility just to comply with this PEP!


Although practicality beats purity.


Regarding the above rule, there may always be an exception to the rule.


Errors should never pass silently.


Never let errors, which may occur, confuse the reader. This may easily be resolved by printing a string when an error occurs.


Unless explicitly silenced.


Unless you are deliberately silencing the error. Even then, be clear about it.


Now is better than never.


According to Jonrsharpe, “ Don’t spend too much time planning and pre-optimising; get something down that does the job and iterate on it (or: fix that issue now rather than putting it off).”. I also imagine this as meaning ‘don’t procrastinate’ or ‘don’t put off the inevitable.’


If the implementation is hard to explain, it's a bad idea.


If the implementation is complicated, it is definitely not simple, meaning it is nowhere near a final draft, meaning it’s not good to put out as one.


In the face of ambiguity, refuse the temptation to guess.


There should be one — and preferably only one — obvious way to do it. 


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.


Although never is often better than right now.


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!