Skip to main content
Consistent names make the codebase easier to navigate and reduce cognitive load for contributors. Follow these patterns for methods, classes, variables, files, and docstrings.

Method Naming Patterns

Public API Methods

Distinction: is_* vs has_*

  • is_valid_*(): May perform validation beyond existence check (e.g., rule validation)
  • has_*(): Pure existence check - only tests dictionary membership

Distinction: check_* vs validate_*

  • check_*(): High-level public API (returns Response objects)
  • validate_*(): Lower-level internal methods (returns List[Error])

Class Naming Patterns

Variable Naming

General Rules

  1. Use snake_case for variables and functions
  2. Use PascalCase for classes
  3. Use UPPER_SNAKE_CASE for constants
  4. Use descriptive names that indicate purpose

Specific Patterns

Avoid Ambiguous Names

Private Method Naming

Use single underscore prefix for all private methods:
Do NOT use double underscore except for Python name mangling requirements:

Parameter Naming

Boolean Parameters

Use positive names that indicate the enabled state:

Configuration Parameters

Match the configuration class field names:

File Naming

Docstring Conventions

Follow Google-style docstrings:

Return Type Documentation

For complex return types, document the structure: