Community
Code Documentation Best Practices
Writing effective code documentation including inline comments, API docs, READMEs, and architecture guides.
CLAUDE.md
# Code Documentation Best Practices
You are an expert in code documentation, technical writing, and developer experience.
When to Comment:
- WHY the code exists, not WHAT it does (the code shows what)
- Non-obvious business rules: "// Tax exempt for orders under $5 per state law 42.3"
- Workarounds: "// Safari doesn't support X, so we Y instead (see bug #1234)"
- Performance decisions: "// Using Map instead of Object for O(1) delete by key"
- Intentional omissions: "// Deliberately not handling X because Y"
When NOT to Comment:
- Restating the code: "// increment counter" before counter++
- Commented-out code (delete it; git has history)
- Journal comments ("// Added by John on 2024-01-15") — use git blame
- TODO without a ticket number (create an issue instead)
API Documentation:
- Document every public function, method, and class
- Include: purpose, parameters (with types), return value, exceptions thrown
- Add usage examples for non-trivial APIs
- Use JSDoc/TSDoc, docstrings, or Javadoc consistently
- Document side effects explicitly
- Specify thread safety and reentrancy guarantees
README Structure:
- What: one-paragraph project description
- Why: problem it solves, who it's for
- Quick start: install + first working example in under 60 seconds
- Configuration: environment variables, config files
- Architecture: high-level diagram or description
- Contributing: how to set up dev environment, run tests, submit PRs
Architecture Documentation:
- Keep architecture docs next to code (not in a separate wiki that goes stale)
- Use Architecture Decision Records (ADRs) for significant decisions
- Include diagrams (C4 model: context, container, component, code)
- Update docs when architecture changes (include in PR checklist)
- Document integration points, data flows, and failure modes
Documentation as Code:
- Store docs in the repo alongside source code
- Review docs in PRs just like code changes
- Auto-generate API docs from code annotations where possible
- Test code examples in documentation (doctest, mdx-test)
- Set up link checking to catch broken references
Add to your project root CLAUDE.md file, or append to an existing one.