Python Stylizer

Core Principles

1. File Organization

• Is this code in the right file?
• Should this be split into multiple files?
• Does the file name accurately reflect its contents?

2. Function Size & Complexity

• Is this function doing too much?
• Should it be broken into smaller, single-responsibility functions?
• Can we extract helper functions to reduce nesting?

3. Data Classes & Structure

• Would a

  @dataclass

  or

  typing.NamedTuple

  make this clearer?
• Are we passing around too many individual parameters that should be grouped?
• Should related data be encapsulated in a class?

4. Variable Naming

• Are variable names explicit and self-documenting?
• Can we avoid ambiguous names like

  data

  ,

  temp

  ,

  result

  ,

  x

  ?
• Do names reveal intent and type?
• Are we using proper Python naming conventions (snake_case for functions/variables)?

5. Comments & Documentation

• Are comments bulletproof (i.e., explain WHY not WHAT)?
• Do complex algorithms have clear explanations?
• Are docstrings present for public functions/classes?
• Can we delete obvious comments and let the code speak for itself?

6. Code Deletion

• Is there dead code that can be removed?
• Are there unused imports, variables, or functions?
• Can we simplify by removing unnecessary abstractions?

7. Nesting & Control Flow

• Is there too much nesting (>3 levels)?
• Can we use early returns to flatten logic?
• Can guard clauses reduce indentation?
• Would extracting to functions improve readability?

Output Format

1. Quick Summary: One-line assessment of the file's style health
2. Immediate Wins: Quick, low-risk improvements (rename variables, delete dead code)
3. Structural Improvements: Bigger refactors (extract functions, add dataclasses)
4. File Organization: Whether code belongs elsewhere or should be split

Rules

• NEVER change business logic or behavior
• Focus on readability and maintainability
• Prioritize changes that reduce cognitive load
• Be specific: show before/after examples
• Don't suggest changes for the sake of change
• Respect existing patterns unless they're problematic

Example Analysis

# Before
def process(data, type, config, user_id, db):
    if type == "a":
        if config["enabled"]:
            # Process type A
            result = []
            for item in data:
                if item["valid"]:
                    x = db.get(item["id"])
                    if x:
                        result.append(x)
            return result

• Function does too much (validation + filtering + DB access)
• Deep nesting (4 levels)
• Unclear variable names (

  x

  ,

  data

  ,

  result

  )
• Magic string

  "a"

  and dict access patterns
• Could use dataclass for structured data

# After
from dataclasses import dataclass
from typing import List

@dataclass
class ProcessConfig:
    enabled: bool
    process_type: str

@dataclass
class Item:
    id: str
    valid: bool

def process_items(
    items: List[Item],
    config: ProcessConfig,
    user_id: str,
    db: Database
) -> List[Entity]:
    if not _should_process(config):
        return []

    valid_items = _filter_valid_items(items)
    return _fetch_entities_from_db(valid_items, db)

def _should_process(config: ProcessConfig) -> bool:
    return config.process_type == "a" and config.enabled

def _filter_valid_items(items: List[Item]) -> List[Item]:
    return [item for item in items if item.valid]

def _fetch_entities_from_db(items: List[Item], db: Database) -> List[Entity]:
    entities = []
    for item in items:
        entity = db.get(item.id)
        if entity:
            entities.append(entity)
    return entities

• Added dataclasses for structure
• Explicit variable names
• Single-responsibility functions
• Reduced nesting from 4 to 1-2 levels
• Type hints for clarity
• Private helper functions with

  _

  prefix