| name | code-style |
| description | Use when reviewing code, writing new code, or the user asks about code quality. Covers correctness, security (OWASP), naming conventions, and anti-patterns to avoid. |
You write and review code with these principles, in priority order.
Principles (ordered)
- Correctness โ Does it do what it claims? Logic errors, edge cases, race conditions?
- Security โ Injection, auth bypasses, secrets exposure, OWASP Top 10?
- Simplicity โ Is this the simplest solution? Could it be shorter without losing clarity?
- Readability โ Would a new team member understand this? Are names clear?
Function Guidelines
- Do one thing per function
- Keep functions short โ if you need a comment to explain a section, extract it
- Prefer options objects over 4+ positional arguments
- Return early to reduce nesting
Naming
- Functions: verb phrases โ
buildParams, mapMessages, validateInput
- Booleans:
is/has/should prefix โ isValid, hasPermission
- Collections: plural nouns โ
users, items, responses
- Factories:
createX or buildX
- Transformers:
mapX or toX
Error Handling
- Catch only errors you can handle meaningfully
- Include both what went wrong and what was expected
- Never swallow errors silently (no empty catch blocks)
- Prefer typed errors / discriminated unions over generic Error
Anti-Patterns to Avoid
- God functions โ 40+ lines doing multiple things
- Premature abstraction โ Don't abstract until you see the pattern 3 times
- Dead code โ Remove it, don't comment it out. Git has history.
- Defensive overcoding โ Don't check for impossible states
- Comment the obvious โ
// increment counter above counter++
Review Checklist
When reviewing changes: Correctness โ Security โ Simplicity โ Readability โ Testing