ReviseAlgo Logo

Basic Syntax

Naming Conventions

PEP 8 style guide for naming

Interview: Code quality

Last Updated: June 12, 2026 • 5 min read

Following PEP 8 naming conventions makes your code consistent, readable, and professional. These are not just style preferences — they signal intent and scope to other Python developers.

Naming Patterns

  • Variables & Functions: snake_case — e.g., user_name, calculate_total()
  • Classes: PascalCase — e.g., UserProfile, HttpClient
  • Constants: UPPER_SNAKE_CASE — e.g., MAX_RETRIES, DEFAULT_TIMEOUT
  • Modules & Packages: short, lowercase — e.g., utils, http_client
  • Private: prefix with single underscore — e.g., _internal_method, _private_var
  • Strongly private: prefix with double underscore — e.g., __mangled_name (triggers name mangling)
  • Magic methods: double underscore prefix and suffix — e.g., __init__, __str__

Best Practices

  • Use descriptive names: user_age not a
  • Avoid single-character names except for loop counters (i, j) or math formulas
  • Boolean variables should read as questions: is_valid, has_permission, can_edit
  • Avoid shadowing built-ins: don't use list, dict, str, id as variable names

Use Cases

Maintaining consistent code style in team projects

Signaling API visibility (public vs private) through naming

Improving code readability for onboarding and reviews

Passing code reviews and linting checks (Ruff, flake8)

Common Mistakes

Using camelCase for functions (Python uses snake_case)

Shadowing built-in names (list, dict, str, id)

Using single underscore prefix without understanding it is just a convention

Not using descriptive names for variables and functions