This article was created by Anthony Reid, and is available at AnthonyReid99/VisualGitDocsand at

Python Coding Style Conventions

1. Whitespace

1.1. Indentation

  • Lines should be indented with a multiple of 4 spaces depending on indent level
  • Hanging indents, code that is a continuation of the line above, should be indented to the next level
  • Use spaces exclusively, no tabs!

1.2. Blank Lines

  • Leave 2 blank lines between class definitions and module-level functions
  • Leave 1 blank line between methods in a class
  • Use blank lines as needed in functions, methods, and modules to visually split up logical blocks of code

1.3. Spaces In Code

  • Surround binary operators with a space on each side
  • Do not include spaces around ‘=’ when used to indicate a default argument or keyword argument
  • In all other cases, extraneous spaces are frowned upon

2. Imports

  • Imports should occur at the top of the module, after any module docstring
  • Standard imports (those beginning with “import”) should each be on a separate line. Do not combine imports into one line.
  • “From … import …”-style imports may be combined together on one line if possible
  • Wildcard imports should only be used when absolutely necessary, otherwise only import the modules to be used

3. Code Blocks

  • Do not use parenthesis in the condition for a code block header unless it would be otherwise appropriate to use parenthesis around that condition
  • Do not use any single line code blocks. Even those with a single statement in the body should occupy multiple lines


  • First and foremost, comments should be up to date and accurate. When updating code, always make sure to update any comments that refer to it
  • Comments should be wrapped to 72 characters
  • Use plain English sentences with proper spelling and grammar. Strongly prefer complete sentences.
  • Single sentence comments need not end in a period
  • Clever humor is acceptable on occasion
  • Do not merely summarize the code that follows. State its overall purpose, justify its inclusion, or explain quirks that other programmers may need to know

4.1. Docstring Comments

  • Docstring comments should consist of a short summary line, optionally (but usually) followed by a blank line, then additional paragraphs with further explanation
  • All classes and methods should contain a docstring
  • Modules should contain a docstring if they serve a purpose other than as a container for a class