casing-lawlisted

# Casing Is Law, Not Preference Mixed casing in a codebase is not a style disagreement. It is a defect. When `getUserName` sits next to `get_user_email` in the same file, the reader cannot predict the shape of the next function. Predictability is the foundation of readable code. Every language has established casing conventions. Follow them absolutely, enforce them mechanically, and treat violations the same way you treat failing tests. ## The Universal Casing Table Every identifier in your codebase falls into one of these categories. The casing is determined by the language and the identifier's role. There is no room for personal preference. ### Python | Identifier Type | Convention | Example | |----------------|------------|---------| | Variables | `snake_case` | `user_count`, `max_retries` | | Functions | `snake_case` | `fetch_active_users`, `calculate_tax_rate` | | Method names | `snake_case` | `def validate_email(self)` | | Function parameters | `snake_case` | `def create_order(customer_id, line_items)` | | Classes | `PascalCase` | `UserProfile`, `PaymentProcessor` | | Exceptions | `PascalCase` | `InvalidTokenError`, `RateLimitExceeded` | | Constants | `UPPER_SNAKE_CASE` | `MAX_RETRY_COUNT`, `DEFAULT_TIMEOUT_SECONDS` | | Modules (files) | `snake_case` | `user_profile.py`, `payment_processor.py` | | Packages (directories) | `snake_case` (short, no underscores preferred) | `payments`, `userprofiles` | | Type aliases | `PascalCase` | `UserId = str`, `OrderItems = list[