The Zen of Python by Tim Peters are guidelines for how you should write your Python code. Your code doesn’t have to follow these guidelines, but it's good to keep them in mind.
>>> import this
"""The Zen of Python, by Tim Peters
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!"""
Beautiful is better than ugly
I believe this is already self-explanatory, but I'll still go over this. It simply says that beautiful code is better than ugly code. Writing a program that once read is easily understood is better than one that'll give the reader some time to figure out. Of course, not every script needs to be beautiful, and beauty is subjective, but much of Python’s popularity results from being so easy to use.
# code 1
file = "lyrics.txt"
open("disordered.txt", "w").write("\n".join(map(lambda x: x[::-1], open(file, "r").read().split("\n")[::-1])))
# code 2
file = "lyrics.txt"
# first read the input file
lyrics = open(file, "r").read()
# split the lyrics into lines and reorder it in reverse form
lyrics = lyrics.split("\n")[::-1]
# reverse each line in the lyrics
reverse = lambda x: x[::-1]
lyrics = list(map(reverse, lyrics))
# merge the new lyrics together
lyrics = "\n".join(lyrics)
# save the file
open("disordered.txt", "w").write(lyrics)
Which of these codes do you prefer and feel is easy to understand?
Explicit is better than implicit
This means that you should avoid hiding your code functionality behind obscure language features that require familiarity to understand fully. Let your code be readable by a stranger who knows nothing about you or your program. Refer back to the code above
Simple is better than complex
This tells us that when building anything, it can be done using simple techniques. When presented with a simple problem, solve it with a simple solution, and when presented with a complex issue, break it into simpler parts, and solve them with simple solutions.
Complex is better than complicated
Going back to the previous rule, some problems don't have a simple solution to solving them, and in such cases, you'll have to use a complex answer. But this is better than using a complicated one. Choose simplicity to complexity, but know the limits of simplicity.
Flat is better than nested
Programmers love to organize things into categories, especially categories that contain subcategories that contain other sub-subcategories. It’s okay to have code in just one top-layer module or class instead of splitting up across multiple submodules or subclasses. Suppose you make packages and modules that require code like import spam.eggs.bacon.ham.foo.bar, then you’re making your code too complicated.
Sparse is better than dense
This refers back to the code sample above. As programmers, we might want to do a lot of functionality with just one line of code. However, spreading code over many lines is better than having one line do all the work.
Readability counts
This means your code should be easily readable, Instead of using single-letter variables or not indenting (however, Python forces this). Use what will be read and easily understood by yourself and other developers. Remember Code is read more often than it’s written
Special cases aren’t special enough to break the rules
Programming is full of best practices that programmers should strive for in their code. Skirting these practices for a quick hack may be tempting but can lead to a rat’s nest of inconsistent, unreadable code.
Although practicality beats purity
There may be cases where you might want to make an exception to the rule above. Bending over backward to adhere to regulations can result in highly abstract, unreadable code. Walking the line between these two rules becomes easier with experience. And in time, you’ll not only learn the rules but also learn when to break them.
Errors should never pass silently
Never let occurring errors that confuse the reader. You can quickly resolve this by printing a string when an error occurs. Just because programmers often ignore error messages doesn’t mean the program should stop emitting them.
Unless explicitly silenced
You can always choose to ignore the errors your programs cause explicitly. Just be sure you are making the conscious choice to do so and be clear about it.
In the face of ambiguity, refuse the temptation to guess
If your code isn’t working, there is a reason, and only careful, critical thinking will solve it. Refuse the temptation to try solutions until something seems to work blindly; often, you have merely masked the problem rather than solved it.
There should be one -- and preferably only one -- obvious 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 to read it. This flexibility isn’t worth the 3x or 4x effort needed to learn a programming language.
Although that way may not be obvious at first unless you’re Dutch
This line is a joke. Guido van Rossum, the creator of Python, is Dutch. Learning or recalling a rule in Python would be easier for him than it would be for anybody else, on average.
Now is better than never
This tells us that we should not spend too much time planning and pre-optimizing; get something down that does the job and iterate on it. Don’t procrastinate and Don’t put off the inevitable
Although never is often better than right now
This refers to the previous rule that we should put some thought into what we are doing so you don’t head off down a path that later has no graceful way back up.
If the implementation is hard to explain, it’s a bad idea
This tells us that If the implementation is complicated, it is not simple, meaning it is nowhere near a final draft, meaning it’s not good to put out as one.
If the implementation is easy to explain, it may be a good idea
These two rules remind us that if high-performance code is so complicated as programmers can't understand and debug, it’s destructive code. But alas, just because it’s easy to explain a program’s code to someone else doesn’t mean it isn’t destructive code.
Namespaces are one honking great idea — let’s do more of those!
Namespaces (and global and local scopes) are vital for preventing names in one module or scope from conflicting with names in another. 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 add needless categorization.