Introduction :
Python was created keeping 20 principles in mind:
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!
When programming in python we need to give higher focus to readability, thus pythonic code creation is good to learn.
This style guide is a list of do’s and don't for Python programs. It follows Python Enhancement Proposals (PEP8) .
DocString
Every python file in the project must have a docstring1
Source file encoding
Code in the core Python distribution should always use UTF-8 (or ASCII in Python 2). A comment or docstring needs to mention an author name and encoding at the start of the source code.
Indentation
Use 4 spaces per indentation level. In python spaces are preferred indentation method. Python 3 doesn't allow mixing tabs and spaces for indentation that is why one need to be carefule.
Maximum line length
It is good to keep 79 character length of a line in python code, so that one can see see whole expression without scrolling horizontally as well to files can be compared at the same time.
For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.
Blank lines
Surround top-level function and class definitions with two blank lines.
Method definitions inside a class are surrounded by a single blank line.
Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).
Use blank lines in functions, sparingly, to indicate logical sections.
Imports
Imports should usually be on separate lines not all packages should be imported in same line.
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
It is good to group the similar type of libraries together the order should be:
1. standard library import
2. related third party import
3. local library/application file import
Absolute imports are highly recommended as they explicitly help to avoid over rights.
wildcard imports should be avoided as they are unclear and unreadable (unless you are overwriting an original package implementation).
Whitespaces
Avoid trailing whitespace anywhere. Because it's usually invisible, it can be confusing: e.g. a backslash followed by a space and a newline does not count as a line continuation marker. Some editors don't preserve it and many projects (like CPython itself) have pre-commit hooks that reject it.
Always surround these binary operators with a single space on either side: assignment (=), augmented assignment (+=, -=etc.), comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not), Booleans (and, or, not).
If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator.
Don't use spaces around the = sign when used to indicate a keyword argument or a default parameter value.
Function annotations should use the normal rules for colons and always have spaces around the -> arrow if present.
When combining an argument annotation with a default value, use spaces around the = sign (but only for those arguments that have both an annotation and a default).
Compound statements (multiple statements on the same line) are generally discouraged.
Note:
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.
However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!
In particular: do not break backwards compatibility just to comply with this PEP!
Python tools for code complexity and static code check