← Home

007. Naming Conventions

Consistent style is a social contract

007. Naming Conventions

Aryan shows his RAM monitor to a senior developer at a hackathon. She spots this immediately:

def getProcessInfo(processName, memUsageMB):
    warningThreshold = 500
    ...

“This is valid Python,” she says, “but it reads like JavaScript. Every Python developer who opens this file will feel friction. PEP 8 is the social contract — when you follow it, your code feels like it belongs.”

PEP 8 rule: variables and functions use snake_case. Classes use PascalCase. Constants use UPPER_CASE.

Aryan needs to rename his player info utility (written during a C-habit phase) to follow the Python convention before code review.

💡 Fun fact: PEP 8 — the Python style guide that mandates snake_case — was written by Guido van Rossum himself in 2001, just 10 years after Python’s first release. Tools like flake8 and black now enforce it automatically, making style disagreements largely a non-issue in professional teams.

⚠️ Watch out: The most common mistake is mixing conventions within a project — some functions in camelCase, some in snake_case. Python will run it fine, but every new developer reading the code will waste mental effort figuring out which style to follow.

🤔 Think about it: Naming conventions are not enforced by the language — Python happily runs camelCase code. So who actually benefits from following PEP 8, and at what point does style become important enough to enforce automatically with a linter?

Learning objectives

  • Apply PEP 8 snake_case naming to variables and functions
  • Distinguish Python naming conventions from other languages
  • Understand the role of PEP 8 in Python culture

Key concepts

  • naming conventions
  • snake_case
  • PEP 8

Try it

Concept detail
PEP 8 is Python’s official style guide. Its naming conventions exist so that any Python developer can open any Python codebase and immediately recognize what kind of thing each name refers to.
Rules:
  • Variables and functions: snake_case (all lowercase, words joined by underscores)
  • Classes: PascalCase (each word capitalized, no separators)
  • Module-level constants: UPPER_CASE
  • “Private” members: _leading_underscore (convention, not enforced)
These are conventions, not language rules. Python will happily run camelCase code. But violating them has a real cost: every Python developer who reads your code has to spend cognitive effort translating your naming scheme instead of focusing on logic. Consistency within a codebase matters more than any specific style, but if you’re writing Python, PEP 8 is what the community expects.
Tools like flake8 and black enforce PEP 8 automatically in professional projects.
Solution
def get_player_info(player_name, total_score, max_level):
    bonus_points = total_score * 0.1
    final_rank = total_score + bonus_points
    return {"name": player_name, "rank": final_rank, "max": max_level}
Tests
def test_function_name_is_snake_case():
    assert callable(get_player_info), "Function should be named get_player_info"

def test_basic_result():
    result = get_player_info("Ada", 100, 5)
    assert result["name"] == "Ada"

def test_rank_calculation():
    result = get_player_info("Ada", 100, 5)
    assert result["rank"] == 110.0

def test_max_level():
    result = get_player_info("Bob", 200, 10)
    assert result["max"] == 10
Resources