ProgrammingPython Team Lead

Tell us about naming conventions (PEP8 and others) in Python. How does not following these conventions affect coding practices? Provide examples of real consequences of violating PEP8 in projects.

Pass interviews with Hintsage AI assistant

Answer.

In Python, there are several style guidelines, the main one being PEP8:

  • Variable/function names: lower_case_with_underscores
  • Class names: CapitalizedCamelCase
  • Constants: ALL_CAPS
  • Line length: up to 79 characters
  • Indentation: 4 spaces (no tabs!)
  • Spaces around operators: a = b + c
  • Imports: each import on a separate line, starting with standard libraries, then third-party, then local

Following PEP8 facilitates teamwork, enhances readability, lowers the entry threshold, simplifies test automation, and more.


Trick question.

PEP8 recommends not using single-letter variable names. However, can you use short names in list comprehensions or in lambda functions? Why?

Answer: In basic cases for short iterations (for example, in list comprehensions for marker variables like x, i, j), single-letter names are acceptable to avoid cluttering short expressions. For complex expressions, it is better to give meaningful names.

Example:

# Acceptable: squares = [x**2 for x in numbers] # Better: squares = [number**2 for number in numbers]

Examples of real mistakes due to ignorance of the nuances of the topic.


Story 1

In a banking project, it was encountered that some functions and parameters were named in different conventions (CamelCase, snake_case, hyphenated). A new team member constantly got confused about where the names were used — almost two weeks were spent resolving collisions and renaming variables.


Story 2

In a data engineering project, indentation was not followed, mixing tabs and spaces. This led to SyntaxError on different dev stations, and some developers spent hours searching for unnecessary spaces.


Story 3

On a large educational portal, short and long variable names were mixed. For example, a function for processing logs was named l(), while the login handler was named long, which in many IDEs took a lot of time for navigation and caused confusion in using the function with the element l from the list.