Python Coding Standards

vivek keshore

5 min readAug 22, 2019

I am working as an Architect at SenecaGlobal, Inc.

There are certain standard coding practices which are defined by PEP (Python Enhancement Proposals).

So, I am writing down some of the most common standard coding practices, pep8 and international standards.

Python pep8 style guide — https://www.python.org/dev/peps/pep-0008/

Object Naming:

Any variable, method, object or module name should be in snake case. Ex. my_var, def my_method()
Object/variable name should not be a python keyword or any inbuilt python method name. Eg. str, for, type etc.
_ (underscore) is a valid variable name, and it can be used when the variable will not be used at any place.
Example:

Another better way of naming a object which goes unused, is by prefixing it with “unused_”
Example:

If it is necessary to name a object which is a python keyword or inbuilt method name, then it should be suffixed with underscore.
Example:

Class name should be CamelCase and first letter should be capitalized.
Constants should always be named in CAPITALIZED_SNAKE_CASE format. All constants should be placed after import statements and before the code.
Do not use one letter to name anything. Use proper self explanatory variable naming.
Example:

In Python there is nothing private or protected. Python assumes that developer are smart enough to treat protected and private objects as they should be treated. So, there is a convention which is used to mark the object which should be treated as private or protected.
Prefix a single underscore if you want to treat the method or object as an protected object.
Prefix double underscore if you want to treat the method or object as an private object.
Example:

Code Comments:

For multi-line comments, triple “““ or triple ‘’’ can be used.
For single line comment, # is used. If code and comment are in same line, then give two spaces after code and one space after # to write the comment.
Example:

Use of Quotes:

There should be uniformity while using quotes in a single module.
It should be either double quote (“) or single (‘) through out the module.
Preferred is double quotes.
Example:

Imports:

Import order is very important in Python.
Import order should be alphabetical in order.
First write inbuilt direct imports, followed by inbuilt relative imports, followed by third party library imports, followed by self implemented imports.
It is suggested to leave one blank line after each category of import statements.

Lines and spacing:

Leave two blank lines after imports and before code.
Leave two blank lines in between two methods or classes in same module.
Leave the last line as blank in any python file.
Leave one blank line between methods inside a class.
Give a space before and after any operator in code, like =,+, %, -, <=, >= etc
Always give a space after comma in list, tuples, set, dicts, and method arguments.
Always give a space after colon ‘:’ in dict.

Miscellaneous:

Prefer map over comprehension if possible, and comprehension over loop. Map is faster than comprehension than normal loop.
Example:

Single line assignments is preferred over multi-line.
Example:

Always try to return from methods as soon as possible.
Global variables should not be used unless there is no other way.
There should be no more than 80 chars in a line as per pep8, but 120 chars is also an accepted standard.
Should not use line break ‘\’ in a code. Instead use parenthesis and indent the next line.
Should use lambda methods where ever required.
Use context manager whenever possible.
Avoid getter and setter methods. Instead define property and getter setter deleter for the property.

The Zen of Python: Python’s Philosophy

whenever you are in doubt, then just go through the zen of Python and see if you in sync with these principles or not.

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!