What actually Zen of Python is?
Zen of Python, a set of 19 guidelines written by Tim Peters that describes the python programming language.
Is it a Genie for python as it’s name consist of Zen?
No, it is not Genie.But for python developers, one must know what they are and what these guidenlines can actually mean.To view these Guidelines, just
run this command, and here you go.
Let’s discuss each one of them one by one:
- Beautiful is better than ugly: This basically focuses on neatness of your code, generally while writing a program, we developers don’t really concentrate on code readability.However, it is better to write a code which is readable for others as well, like a non coding background person.This also helps other programmers to understand the flow and helps in debugging later on.
- Explicit is better than implicit: This means it is better to explicitly specify the tasks rather than making use of existing ones. However, this is not always necessary because at times the explicit specifications will increase the production time without providing any specific benefit.
- Simple is better than complex: Software Developers have an option to either keep their code simple or make it complex.
print("Hello World") # Simple#Complex
string = print("Hello World")
4. Complex is better than Complicated: This is an elaboration of previous one. As we have seen in the last axiom, that simple is better than complex, the Zen of Python goes on to mention that, complex is still better than complicated. Consider the same example, that we spoke about earlier, is it was quite complex to write a hello World program using a function. So, what could be more complicated than that? Imagine writing a Hello World program using a class, and the number of steps, this will definitelybe more complicated, than what we see in previous example.However, Software Development is not just restricted to Hello World, there are situations where you have no choice take the long way out.
5. Flat is better than nested: This basically indicates that, it is better to have limited upper level modules and classes, the more sub-modules, sub-classes you have, more will be the overhead of writing the code.
6. Sparse is better than dense: Developers generally like to write code with the minimum number of lines, as a result they end up writing code that includes many steps within each line.This does not impact the interpreter any way, but other programmers will have tough time understanding it.
7. Readability Counts: programs that are written by a programmer needs to be verified by various others, involved in software development. Therefore, it is important, that you male your code as readable as possible.Make sure to add comments, whenever required. Use relevant names for your variable, classes, and functions etc.
8.Special cases aren’t special enough to break the rules. Although practicality beats purity: These two axioms, which come as a set, contradict each other. Programming is full of “best practices” that programmers should strive for in their code. Breaking these practices for a quick hack may be tempting, but can lead to an issue of inconsistent, unreadable code. However, bending over backwards to adhere to rules can result in highly-abstract, unreadable code. The Java programming language’s attempt to fit all code to its object-oriented paradigm often results in lots of boilerplate code for even the smallest program. Walking the line between these two axioms becomes easier with experience. And in time, you’ll not only learn the rules, but also learn when to break them.
9.Errors should never pass silently.Unless explicity silenced: Just because programmers often ignore error messages doesn’t mean the program should stop emitting them. Silent errors can happen when functions return error codes or None instead of raising exceptions. These two aphorisms tell us that it’s better for a program to fail fast and crash than to silence the error and continue running the program. The bugs that inevitably happen later on will be harder to debug since they are far removed from the original cause. Though you can always choose to explicitly ignore the errors your programs cause, just be sure you are making the conscious choice to do so.
10.In the face of ambiguity, refuse the temptation to guess: It is obvious, that as a programmer you’ll face ambiguousissues.However, this does not mean that you’re just trying to add some solution that resolves the error, but doesn’t actually solves the issue in your code.Therfore, it is good to think critically and find actual solutions.
11. There should be one — and preferably only one — obvious way to do it: The reason this is, when you have too many solutions, you should have appropriate knowledge of each of them. not just that the testing team would face a lot of issues due to this and a s a result the time taken to study and debug the code would increase.“There’s more than one way to do it!” It turns out that having three or four different ways to write code that does the same thing is a double-edged sword: you have flexibility in how you write code, but now you have to learn every possible way it could have been written in order to read it.
12.Although that way may not be obvious at first unless you’re Dutch: This line is a joke basically add on to the previous axiom. Guido van Rossum, the creator and BDFL (Benevolent Dictator for Life) of Python, is Dutch.
13.Now is better than never. Although never is often better than *right* now: These axioms imply that while coding if there is a solution that can produce result at the same point, should be applied. However, the next statement comes as a warning to developers, not to do something in hurry without adequate knowledge.
14.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: As a programmer, it is important, that the solution you provide not just delivers the desire result but at the same time it should be easy to debug and understand.
15. Namespaces are one honking great idea — let’s do more of those! : The last axiom puts light on namespaces, the namespace , or the local, the global namespace system provides a very oragnized solution to avoid names of different module from clashing with each other. But also remember that flat is better than nested: As great as they are, namespaces should be made only to prevent naming conflicts, and not to add needless categorization.
That’a all for today’s blog
Thanks for giving your valuable time.