It’s better for a program to crash than to silence an error and continue running. Silencing errors eventually leads to bugs that are harder to squash (as it’s harder to track the original cause). If there’s an error and your program returns None or just an error code, you are having a silent error. It can be challenging for programming newbies to navigate between this and the above principle, but it gets easier with experience.
#PRINT ZEN OF PYTHON CODE#
If it’s more practical to solve a problem “your way” and it keeps code readable and easy-to-follow, you may sometimes deviate from established best practices. This rule is especially important when you create modules or libraries for others to use. Follow these practices instead of doing it “your way”. In Python, there are lots of best practices that make your code more readable for fellow programmers. Special cases aren't special enough to break the rules. If you actually want to “save time”, make your code readable by using easy-to-understand variable and function names, extensive documentation, and proper indenting. Remember: You may write code only once, but people will likely need to read it multiple times. Often, programmers try to save time by abbreviating variable and function names or skipping comments (or making comments overly brief). It’s usually preferable to have several easy-to-follow lines of code than a dense one-liner. It might sound impressive to non-programmers but in fact, it just confuses your fellow programmers who’ll need extra time to understand your code. Sparse is better than dense.ĭon’t try to impress anybody by compressing a ton of functionality into one line of code. This is super important for code readability – and as you already know, we care a lot about readability in Python. Stick to a flat code structure with minimal nesting. Flat is better than nested.Īre you a big fan of organizing things in categories, sub-categories, and sub-subcategories? Well, when it comes to organizing your code, this hierarchical structure often adds more confusion than organization. Keep your code as simple and readable as possible, even when working with complex problems. Complicated code makes your fellow programmers confused and sucks up tons of time and effort. When your problem requires a complex solution, it still shouldn't be too complicated.
Don’t overcomplicate your code to look smart.
If you have a complex problem, break it down into several simple problems that can be solved with a simple solution. If you have a simple problem that can be solved with a simple solution, go for it. Make your code as explicit as possible without hiding code functionality behind obscure language. Your code should be understandable to someone who knows nothing about your program. If you want your code to look pythonic, pay attention to its consistency and simplicity.
Python is known for its simplicity, readability, and elegance. If two code snippets are both working but one is simple and easily readable while the other is messy and hard to understand, the first one is definitely the winner. Beautiful is better than ugly.īeautiful code is better than ugly code. So we might actually need to translate these beautifully written principles into actionable insights.
#PRINT ZEN OF PYTHON SOFTWARE#
Principles of the Zen of Python or PEP-20Įven though the principles of the Zen of Python were prepared by a software engineer, they are written in anything but technical language. But first, let’s briefly examine each principle. To display The Zen of Python, run the following command in Python interpreter:Ĭheck out our interactive Learn Programming with Python track to see how these principles are applied with real code. Including these guidelines to PEPs acknowledges them as an important part of Python culture, something that every Python programmer should be aware of. In the case of PEP-20, it is just a list of these 19 principles. PEPs (Python Enhancement Proposals) are documents providing important information to the Python community, or describing a new feature for Python.
0 kommentar(er)
