Code Standards
🐍 Code Standards¤
🪺PEP Guidelines¤
You must adhere to the strict guidelines of coding best practices. Here is a non-exhaustive list of the most important guidelines to follow:
- PEP 8: This is the de-facto code style guide for Python. It is a set of conventions for how to format your Python code to maximize its readability.
- It is a set of conventions for how to format your Python code to maximize its readability.
- PEP 484: This PEP introduces a standard for type annotations in Python. It aims to provide a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring.
- It aims to provide a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring.
- PEP 621: This PEP introduces a mechanism to specify project metadata in a standardized way. It aims to provide a standard way to specify project metadata, making it easier for tools to work with Python projects.
- It aims to provide a standard way to specify project metadata, making it easier for tools to work with Python projects.
- PEP 20: This PEP is a set of aphorisms that capture the guiding principles of Python's design. It is a must-read for any Python developer.
- It is a set of aphorisms that capture the guiding principles of Python's design. It is a must-read for any Python developer.
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!