| name | code-commenting |
| description | Guidelines for writing self-explanatory code with minimal comments. Covers when to comment (WHY not WHAT), anti-patterns to avoid, annotation tags, public API documentation. Use when writing or reviewing code comments, docstrings, TODO/FIXME tags, code readability, or inline comments. |
Code Commenting
Comment WHY, not WHAT. Prefer renaming over commenting.
When to Comment
| Situation | Action |
|---|
| Self-explanatory code | No comment |
| Bad name is the real problem | Rename instead |
| Complex business logic / non-obvious algorithm | Comment WHY |
| Regex, API constraints, gotchas | Comment WHY |
| Public API function/method | JSDoc |
| Magic number / config constant | Inline rationale |
Examples
let counter = 0;
const tax = calculateProgressiveTax(income, [0.1, 0.2], [10000]);
for (let k = 0; k < vertices; k++) { }
await rateLimiter.wait();
const MAX_RETRIES = 3;
const API_TIMEOUT = 5000;
Public APIs — JSDoc
function calculateCompoundInterest(principal, rate, time, n = 1) { ... }
Annotation Tags
| Tag | Use |
|---|
TODO | Planned work |
FIXME | Known bug needing fix |
HACK | Workaround — note why and when to remove |
NOTE | Important non-obvious constraint |
WARNING | Side effect / mutation risk |
PERF | Hot path — optimization opportunity |
SECURITY | Security-sensitive code |
DEPRECATED | Note replacement and removal version |
Anti-Patterns
| Anti-pattern | Rule |
|---|
| Commented-out code | Delete it — git has history |
| Changelog in comments | Use git log |
| Decorative dividers | Use proper file/section structure |
Checklist