SkillRary

 

In 1999, software engineer Tim Peters took to Python’s mailing list to send out 19 guiding principles for developing with the language. These principles, meant to aid developers in writing programs that would influence Python’s evolution, became known as the Zen of Python.

• 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

Programmers often write code quickly without concern for readability. While code doesn’t have to be readable, the code of the Python language itself must be thought out, consistent, and a joy to use. Of course, not every script needs to be beautiful, and beauty is subjective, but much of Python’s popularity is a result of being so easy to work with.

Explicit is better than implicit

It means that it is better to make the code more verbose and explicit. Doing this will make the code readable. Hiding code functionality might have repercussions as other programs might not be able to understand the code.

Simple is better than complex; Complex is better than complicated

These two aphorisms remind us that building anything can be done using simple or complex techniques. With a simple problem, such as building a birdhouse, a simple solution is better. Building a diesel train engine, on the other hand, is a complex problem that requires complex techniques. Even if you could technically make a diesel train engine using birdhouse techniques, you probably would end up with a complicated, Rube Goldberg arrangement of birdhouse parts that wouldn’t be an ideal solution. Prefer 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 which contain other sub-subcategories. These hierarchies often don’t add organization so much as they add bureaucracy. It’s okay to have code in just one top-layer module or class instead of split up across multiple submodules or subclasses. If 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

Programmers often like to cram as much functionality into as little code as possible, such as one-liners like the following:

 print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8)))).

While code like this may impress their friends, it’ll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

Readability counts

While strcmp() may obviously mean the “string compare” function to someone who has been programming in C since the 1970s, modern computers have enough memory to write out the full function name. Don’t drop vowels from your names or write overly terse code. Code is read more often than it’s written, so explicit, readable code is more important than terse, undocumented code.

Special cases aren't special enough to break the rules

These two aphorisms, which come as a set, contradict each other. 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. 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 aphorisms 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. Unless explicitly 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.

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

Computers do what we want them to do. Still, these machines have made us superstitious. There is always a reason why a computer code is not behaving properly. Only and only your logic can fix it. So, break the temptation to guess and blindly try solutions until code works.

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

In Perl programming, there is a saying which says — “There’s more than one way to do it!” Using three-four codes to do the same thing is just like having double-edged sword. Not only it consumes time to write it but every fellow must be able to read your 3–4 methods without any issues. Flexibility in this practice isn’t worth celebrating.

Although that way may not be obvious at first unless you’re Dutch

Referring to Guido van Rossum, Python creator, this aphorism says that the language rule will not be easy to learn or recall unless and until you are the creator of the code. A joke referring to BDFL (Benevolent Dictator for Life)!

Now is better than never. Although never is often better than *right* now

These two aphorisms tell us that code that hangs or gets caught in infinite loops is obviously worse than code that doesn’t. However, it’s almost certainly better to wait for your program to finish than to have it finish too early with incorrect results.

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

Python strives to make the programmer’s job easier rather than accommodate the computer so a program runs faster. And programs need to be understandable not just by the programmer who wrote it, but also by other programmers who maintain the code. These two aphorisms remind us that if “high-performance” code is so complicated as to be impossible for programmers to understand and debug, then it’s bad code. But alas, just because it’s easy to explain a program’s code to someone else doesn’t mean it isn’t bad code. Programming is hard.

Namespaces are one honking great idea—let’s do more of those!

Namespaces (and also global and local scopes) are key 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 to add needless categorization.