Python Code Formatting Guide: PEP8

When writing Python code, it’s important to create readable, understandable, and maintainable code. But how can you ensure your code is truly easy to understand and adheres to best practices? This is where PEP8, the official Python coding style guide, comes in. It defines the rules for formatting and writing code. In this article, we’ll explore the key recommendations from PEP8 and learn how to apply them in practice to ensure your Python code not only fulfills its purpose but is also understandable to your colleagues (and to you in six months).

Indents

• Use 4 spaces for each indentation level.
• The extra lines should align the wrapped elements.Option 1 vertical:
  foo = function_name(var_one, var_two, var_three, var_four)


  Option 2 with indentation (then there should be no arguments in the first line):

  foo = function_name(
var_one, var_two,
var_three, var_four)

• In multi-line constructions, it is better to place closing parentheses under the first non-space character of the last line:
  my_list = [
1,2,3,
4,5,6,
]

• Also, closing parentheses can be aligned below the first character of the line that starts the multi-line construct:
  my_list = [
1,2,3,
4,5,6,
]


Maximum line length

• Limit all lines to 79 characters.
• Lines containing text (documentation or comments) should be limited to 72 characters.
• Long lines can be broken into multiple lines by enclosing expressions in parentheses.

Blank lines

• Separate top-level function and class definitions with two blank lines.
• Separate methods within a class with one blank line.
• Additional blank lines may be used (in small numbers) to separate groups of related functions.
• There must be a blank line between each import group.

Import

• Imports must be on separate lines:
  # Right:
import os
import sys

  #Wrong:
import sys, os


  Although it is also possible:

  from subprocess import Popen, PIPE

• Imports are always placed at the top of the file, immediately after comments and docstrings, and before global variables and module constants.
• Imports should be grouped in the following order:
  1. Standard Import Library.
  2. Related third-party imports.
  3. Import for a local application or library.

Spaces

Avoid unnecessary spaces:

• Inside and before parentheses:
  #Right:
spam(ham[1])

  # Wrong:
spam ( ham[ 1 ] )

• Between the comma and the closing parenthesis:
  # Right:
foo = (0,)

  # Wrong:
bar = (0, )

• More than one space around an assignment (or other) operator:
  # Right:
x = 1
y = 2
long_var = 3

  # Wrong:
x = 1
y = 2
long_var = 3


Naming styles

The following naming styles are commonly distinguished:

• b (one lowercase letter)
• B (one capital letter)
• lowercase
• lower_case_with_underscores
• UPPERCASE
• UPPER_CASE_WITH_UNDERSCORES
• CapitalizedWords
• mixed case
• Capitalized_Words_With_Underscores

Names to Avoid

• ‘l’, ‘O’, or ‘I’ as single-character variable names
• __name__
• _name
• name_

Naming rules

• Packages and modules: lowercase, lower_with_underscores
• Classes: CapitalizedWords
• Global variables: lowercase, lower_with_underscores, __all__
• Functions and variables: lowercase, lower_with_underscores
• Function and method arguments: self is the first argument for instance methods, cls is the first argument for class methods
• Constants: UPPERCASE, UPPER_WITH_UNDERSCORES

Conclusion

Following these guidelines may not seem so important at first, especially when the code works without them. However, as practice shows, structured and neat code not only makes your work easier but also makes it easier for other developers to understand. Remember: good programming style is not just a matter of aesthetics; it’s a testament to your professionalism.