|
| 1 | +# Python Coding Style Specification |
| 2 | + |
| 3 | +## Core Principles |
| 4 | + |
| 5 | +### 1. Favor Simplicity Over Complexity |
| 6 | +- **Always choose the simple, straightforward solution** over complex or "sophisticated" alternatives |
| 7 | +- **Avoid over-engineering** - resist the urge to build elaborate abstractions unless clearly needed |
| 8 | +- **No premature optimization** - especially avoid blind optimization without measurement |
| 9 | +- **Use simple building blocks** that can be composed elegantly rather than complex features |
| 10 | +- **Principle**: If there are two ways to solve a problem, choose the one that is easier to understand |
| 11 | + |
| 12 | +### 2. Clarity is Key |
| 13 | +- **Readable code beats clever code** - optimize for the reader, not the writer |
| 14 | +- **Use clear, descriptive names** for variables, functions, and classes |
| 15 | +- **Format code for maximal scanning ease** - use whitespace and structure intentionally |
| 16 | +- **Document intent and organization** with comments and docstrings where helpful |
| 17 | +- **Reduce cognitive load** - code should express intent clearly at a glance |
| 18 | +- **Principle**: The easier your code is to understand immediately, the better it is |
| 19 | + |
| 20 | +### 3. Write Pythonic Code |
| 21 | +- **Follow Python community standards and idioms** for naming, formatting, and programming paradigms |
| 22 | +- **Cooperate with the language** rather than fighting it |
| 23 | +- **Leverage Python features** like generators, itertools, collections, and functional programming |
| 24 | +- **Write code that looks like Python wrote it** - use established patterns and conventions |
| 25 | +- **Examples of Pythonic patterns**: |
| 26 | + - List comprehensions over explicit loops when appropriate |
| 27 | + - Context managers (`with` statements) for resource management |
| 28 | + - Generator expressions for memory efficiency |
| 29 | + - `enumerate()` instead of manual indexing |
| 30 | + - `zip()` for parallel iteration |
| 31 | + |
| 32 | +### 4. Don't Repeat Yourself (DRY) |
| 33 | +- **Avoid code duplication** to make code more maintainable and extendable |
| 34 | +- **Use functions and modules** to encapsulate common logic in single authoritative locations |
| 35 | +- **Consider inheritance** to avoid duplicate code between related classes |
| 36 | +- **Leverage language features** like default arguments, variable argument lists (`*args`, `**kwargs`), and parameter unpacking |
| 37 | +- **Eliminate duplication through abstraction** - but don't abstract too early |
| 38 | + |
| 39 | +### 5. Focus on Readability First |
| 40 | +- **PEP8 is a guide, not a law** - readability trumps mechanical adherence to style rules |
| 41 | +- **Make code as easy to understand as possible** - this is the ultimate goal |
| 42 | +- **Deliberately violate guidelines** if it makes specific code more readable |
| 43 | +- **Consider the human reader** first when making formatting and style decisions |
| 44 | +- **Principle**: Rules serve readability, not the other way around |
| 45 | + |
| 46 | +### 6. Embrace Conventions |
| 47 | +- **Follow established conventions** to eliminate trivial decision-making |
| 48 | +- **Use PEP8 as a baseline** but prioritize readability when there's conflict |
| 49 | +- **Establish consistent patterns** in your codebase for common tasks: |
| 50 | + - Variable naming patterns |
| 51 | + - Exception handling approaches |
| 52 | + - Logging configuration |
| 53 | + - Import organization |
| 54 | +- **Consistency enables focus** - familiar patterns let readers focus on logic rather than parsing |
| 55 | + |
| 56 | +## Specific Implementation Guidelines |
| 57 | + |
| 58 | +### Naming Conventions |
| 59 | +- **Variables and functions**: `snake_case` |
| 60 | +- **Classes**: `PascalCase` |
| 61 | +- **Constants**: `UPPER_SNAKE_CASE` |
| 62 | +- **Private attributes**: `_single_leading_underscore` |
| 63 | +- **Choose descriptive names** that clearly indicate purpose and content |
| 64 | + |
| 65 | +### Code Structure |
| 66 | +- **Organize imports** in this order: standard library, third-party, local imports |
| 67 | +- **Use blank lines** to separate logical sections |
| 68 | +- **Keep functions focused** on a single responsibility |
| 69 | +- **Prefer composition over inheritance** when appropriate |
| 70 | +- **Write functions that do one thing well** |
| 71 | + |
| 72 | +### Documentation |
| 73 | +- **Write docstrings** for modules, classes, and functions that aren't immediately obvious |
| 74 | +- **Use comments** to explain why, not what |
| 75 | +- **Keep comments up to date** with code changes |
| 76 | +- **Focus on intent** rather than implementation details |
| 77 | + |
| 78 | +### Error Handling |
| 79 | +- **Use specific exception types** rather than generic `Exception` |
| 80 | +- **Follow the "easier to ask for forgiveness than permission" (EAFP) principle** |
| 81 | +- **Handle errors at the appropriate level** - don't catch exceptions you can't handle meaningfully |
| 82 | + |
| 83 | +### Performance and Optimization |
| 84 | +- **Write clear code first** - optimize only when necessary and after measurement |
| 85 | +- **Use appropriate data structures** for the task |
| 86 | +- **Leverage built-in functions** and library functions when they're clearer |
| 87 | +- **Profile before optimizing** - don't guess where bottlenecks are |
| 88 | + |
| 89 | +## Code Review Checklist |
| 90 | + |
| 91 | +When generating or reviewing Python code, ensure: |
| 92 | +- [ ] The simplest solution that works is chosen |
| 93 | +- [ ] Names clearly communicate purpose |
| 94 | +- [ ] Code is easily scannable and readable |
| 95 | +- [ ] Pythonic patterns are used appropriately |
| 96 | +- [ ] No unnecessary duplication exists |
| 97 | +- [ ] Conventions are followed consistently |
| 98 | +- [ ] Comments explain intent where needed |
| 99 | +- [ ] Error handling is appropriate |
| 100 | +- [ ] The code would be easy for another developer to understand and maintain |
| 101 | + |
| 102 | +## Decision Framework |
| 103 | + |
| 104 | +When faced with coding choices, ask: |
| 105 | +1. **Is this the simplest solution that works?** |
| 106 | +2. **Will this be clear to someone reading it in 6 months?** |
| 107 | +3. **Am I using Python idioms appropriately?** |
| 108 | +4. **Am I duplicating logic that could be abstracted?** |
| 109 | +5. **Does this follow our established conventions?** |
| 110 | +6. **Is this optimized for readability?** |
| 111 | + |
| 112 | +The answer to all these questions should be "yes" for beautiful Python code. |
0 commit comments