Python Style Guide

It is believed, code is read more often than written. Writing code with consistency matters. It makes readers life easy.

Python provides PEP8 - Style Guide for Python Code, which was written by Guido van Rossum and others, to provide some guidelines regarding how to write code in Python.

You can read the whole style guide provided by PEP8. But in this blog, I am providing the same information in a more concise way so that you can get to the point quickly.

Here are the guidelines:

Use 4 spaces per indentation level
Spaces are the preferred indentation method and not tab
Limit all lines to a maximum of 79 characters

Break formulas before binary operator

            net_salary = (basic_salary 
                         + hra
                         + da 
                         - tax)

Surround top-level functions and class definitions with two blank lines
Method definitions inside a class are surrounded by a single blank line
Code in the core Python distribution should always use UTF-8
Imports should usually be on separate lines. Import must be at the top of the file. Wildcard imports(import *) should be avoided.
Module level "dunders" (names with two leading and two trailing underscores) such as __author__ and __version_ should be placed after the module docstring but before any import statements
Use either single quote or double quote string consistently. However, when double quote is needed as part of string then use single quote. Triple-quoted strings should be double quoted.
Avoid whitespace immediately inside parentheses, square brackets or braces
Avoid whitespace immediately before a comma, semicolon, or colon
Avoid whitespace anywhere as it is invisible, it can be confusing
Always surround operators (=, ==, >,<, !=, <>, <=, >=, in, not in, is, is not, and, or, not, += etc.) with a space on either side
Don’t use spaces around the = sign when used to indicate a keyword argument or a default parameter value
Use trailing comma when a list of values, arguments or imported items is expected to be extended over time
Never use letters ‘l’ (lowercase letter el), ‘O’ (uppercase letter oh), or ‘I’ (uppercase letter eye) as single character variable names as these characters are indistinguishable from the numerals one and zero
Modules should have short, all-lowercase names. Underscores can be used in the name to improve readability.
Classname should use CapWords (first letter of each word uppercase and remaining lowercase) convention
Exception names should follow CapWords convention and should be suffixed with Error
Function names should be in lowercase, with words separated by underscores
Method names should follow function names convention
Constants are usually defined on a module level and written in all caps with underscore separating words
Public attributes should have no leading underscores
If public attribute name collides with a reserved word, append a single trailing underscore to your attribute name