Skip to content

anyTV/Python-conventions

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 

Repository files navigation

Python Coding Conventions

List of standards for the most commonly used codes and patterns in Python. Conventions will allow developers to create code bases that will be easier for other developers to read and understand.

Use pylint and pep8 for checking if the codes follow standard. To install, run this commands:

pip install pylint
pip install pep8

If you are using Sublime, you can integrate pylint and pep8 through SublimeLinter. See instructions for SublimeLinter-pylint and SublimeLinter-pep8.

Use Python PEP8 Autoformat to automatically format your code to pep8 standards. See docs for instructions.

Naming Convention

  1. General Naming Guide

    • Be descriptive with naming without being too wordy
    • Avoid names using single character as much as possible.
  2. Global Variable Names, Functions, Packages and Modules

    • Package names should be in lower case.
    • Use underscore if multiple words are needed. my_cool_package
    • Avoid Global Variables!
  3. Classes

    • Classes should follow the UpperCaseCamelCase convention. MyVeryOwnClass
    • Exception Classes should end in 'Error'
  4. Instance Variables and Method Names

    • Lowercase with words separated by underscores as necessary to improve readability. my_var, run_method
      • Non-public instance variables should begin with a single underscore. _im_hidden
  5. Constants

    • Constant names must be fully capitalized.
    • Words in a constant name should be separated by an underscore. MY_NEW_CONSTANT

###Code Layout

  1. Maximum line length is 72 characters.

  2. Blank lines

    • Separate top-level function and class definitions with two blank lines.
    • Method definitions inside a class are separated by a single blank line.
    • Use blank lines in functions, sparingly, to indicate logical sections.
  3. Indentation

    Use 4 spaces per indentation level. Hanging indents, code that is a continuation of the line above, should be indented to the next level.

    	
    	#Good
    	
    	# Aligned with opening delimiter.
    	foo = long_function_name(var_one, var_two,
                         		var_three, var_four)
    
    	# More indentation included to distinguish this from the rest.
    	def long_function_name(
        		var_one, var_two, var_three,
        		var_four):
    		print(var_one)
    
    	# Hanging indents should add a level.
    	foo = long_function_name(
    		var_one, var_two,
    		var_three, var_four)
    	
    	#Bad
    	
    	# Arguments on first line forbidden when not using vertical alignment.
    	foo = long_function_name(var_one, var_two,
    		var_three, var_four)
    
    	# Further indentation required as indentation is not distinguishable.
    	def long_function_name(
    		var_one, var_two, var_three,
    		var_four):
    		print(var_one)

    The closing brace/bracket/parenthesis on multi-line constructs may be lined up under the first character of the line that starts the multi-line construct

    	
    	my_list = [
    		1, 2, 3,
    		4, 5, 6
    	]
    	
    	result = some_function_that_takes_arguments(
    		'a', 'b', 'c',
    		'd', 'e', 'f'
    	)
  4. Imports

    • Imports should occur at the top of the module, after any module docstring
    • Use of absolute imports is much more recommended. Wildcard imports should be avoided
    • Standard imports, those that uses the import keyword, should each be in a separate file
    		
    	#Good
    		
    	import os
    	import sys
    		
    	#Not so bad depending on framework used
    		
    	import os, sys
    • Imports should be grouped in the following order:
      1. standard library imports
      2. related third party imports
      3. local application/library specific imports
  5. Whitespaces

    Avoid extraneous whitespace in the following situations:

    	
    	#Good
    	spam(ham[1], {eggs: 2})
    	spam(1)
    	
    	#Bad  
    	spam( ham[ 1 ], { eggs: 2 } )
    	spam (1)
    	
    	
    	#Good
    	if x == 4: print x, y; x, y = y, x
    	
    	x = 1
    	y = 2
    	long_variable = 3
    	
    	#Bad
    	if x == 4 : print x , y ; x , y = y , x
    	
    	x             = 1
    	y             = 2
    	long_variable = 3
    	
    	
    	#Good
    	ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
    	ham[lower:upper], ham[lower:upper:], ham[lower::step]
    	ham[lower+offset : upper+offset]
    	ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
    	ham[lower + offset : upper + offset]		
    	#Bad
    	ham[lower + offset:upper + offset]
    	ham[1: 9], ham[1 :9], ham[1:9 :3]
    	ham[lower : : upper]
    	ham[ : upper]
    	
    	#Good
    	dct['key'] = lst[index]		
    	
    	#Bad
    	dct ['key'] = lst [index]
    	
  6. Other Code Patterns

    Surround operators with white spaces. If operators with different priorities are used, you can group them using spaces.

    	
    	#Good 
    	
    	i = i + 1
    	submitted += 1
    	x = x*2 - 1				#grouped operators
    	hypot2 = x*x + y*y
    	c = (a+b) * (a-b)
    	
    	#Bad
    	
    	i=i+1
    	submitted +=1
    	x = x * 2 - 1
    	hypot2 = x * x + y * y
    	c = (a + b) * (a - b)

    Don't use spaces around the = sign when used to indicate a keyword argument or a default parameter value.

    	
    	#Good
    	
    	def complex(real, imag=0.0):
    		return magic(r=real, i=imag)
    		
    	#Bad
    	
    	def complex(real, imag = 0.0):
    		return magic(r = real, i = imag)

    Don't put multi-clause statements on the same line, especially when dealing with if, for ,while , try, catch.

    	
    		#Really Bad
    	
    		if foo == 'blah': do_blah_thing()
    		else: do_non_blah_thing()
    
    		try: something()
    		finally: cleanup()
    
    		do_one(); do_two(); do_three(long, argument,
                             list, like, this)
    
    		if foo == 'blah': one(); two(); three()
    	

    Use is not operator rather than not ... is

    	#Good 
    
    	if foo is not None:
    	
    	#Bad
    	
    	if not foo is None:

    Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier.

    	#Good
    	
    	def f(x): return 2*x
    	
    	#Bad
    	
    	f = lambda x: 2*x
    	

    When catching exceptions, mention specific exceptions whenever possible instead of using a bare except: clause. Derive exceptions from Exception rather than BaseException

    	try:
    		import platform_specific_module
    	
    	# defines the exception 'ImportError' 
    	# instead of just using the except which will accept BaseException
    	except ImportError:						
    		platform_specific_module = None	
    	

    When binding caught exceptions to a name, prefer the explicit name binding syntax

    	
    	try:
    		process_data()
    	
    	# raise DataProcessingFailedError, str(exc) is not supported in Python 3
    	except Exception as exc:
    		raise DataProcessingFailedError(str(exc))

    Be consistent in return statements. Either all return statements in a function should return an expression, or none of them should. If any return statement returns an expression, any return statements where no value is returned should explicitly state this as return None , and an explicit return statement should be present at the end of the function.

    	
    	#Good
    	
    	def foo(x):
    		if x >= 0:
        		return math.sqrt(x)
    		else:
        		return None
    
    	def bar(x):
    		if x < 0:
        		return None
    		return math.sqrt(x)
    
    	#Bad
    	
    	def foo(x):
    		if x >= 0:
        		return math.sqrt(x)
    
    	def bar(x):
    		if x < 0:
        		return
    		return math.sqrt(x)

    Use .startswith() and .endswith() instead of string slicing to check for prefixes or suffixes.

    	#Good
    	
    	if foo.startswith('bar'):
    	
    	#Bad
    	
    	if foo[:3] == 'bar':
        	

    Object type comparisons should always use isinstance() instead of comparing types directly.

    	
    	#Good
    	
    	if isinstance(obj, int):
    	
    	#Bad
    	
    	if type(obj) is type(1):

    For sequences, (strings, lists, tuples), use the fact that empty sequences are false.

    	#Good
    	
    	if not seq:
    	if seq:
    	
    	#Bad
    	
    	if len(seq):
    	if not len(seq):	

    Don't compare boolean values to True or False using ==

    	
    	#Good
    	
    	if greeting:
    	
    	#Bad
    	
    	if greeting == True:
    	if greeting is True:
    	

References:

  • Pep8 - Style Guide for Python Code
  • Google Python Style Guide
  • Python Coding Conventions by AnthonyReid99 link

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published