Instruction file imported from jmayorga94/spec-driven-development-lab (.github/instructions/simplicity.instructions.md). Copyright stays with the author.

Code Simplicity

Write code that a mid-level developer can read and understand without explanation.

Rules

Prefer explicit over clever

• No one-liners that sacrifice readability for brevity
• Avoid chained LINQ beyond 3 operations — break into named variables or intermediate steps
• No nested ternary operators

Name things clearly

• Variable and method names must describe what they hold or do — no abbreviations, no single-letter names except loop counters (i, j)
• Booleans should read as statements: isActive, hasPermission, wasFound
• Methods should be verb phrases: GetUserById, ValidateRequest, SaveChanges

Keep methods small and focused

• Each method does one thing
• If a method needs a comment to explain what it does, rename it instead
• Target < 20 lines per method; hard limit 40 lines

Avoid premature abstractions

• Do not create base classes, generic helpers, or utility layers unless they are used in at least 3 places
• Do not introduce design patterns (Strategy, Factory, Decorator, etc.) unless the problem genuinely requires it
• Duplication is acceptable when the alternatives are harder to understand

No magic

• No reflection-based tricks, dynamic dispatch, or expression tree manipulation unless it is the only option and is clearly documented
• No custom middleware that silently transforms data without being obvious from the call site

Comments

• Do not add comments that restate the code (// increment i)
• Do add comments when explaining why a decision was made, not what the code does