Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Don't write comments that restate the code
Avoid comments that merely narrate what the adjacent code already says — e.g. listing the CSS/Tailwind classes or property values an element applies, or paraphrasing an obvious statement. Comments should capture intent, constraints, or the non-obvious 'why'; descriptions of literal values add no information and silently drift out of sync when the code changes.
Bad example
| 1 | /** |
| 2 | * Card layout. The card has a gray-25 background, gray-100 border, |
| 3 | * 16px radius, with a title row and a flex-wrap items row. |
| 4 | */ |
| 5 | <div className="flex flex-col rounded-2xl border border-gray-100 bg-gray-25"> |
Explanation (EN)
The comment just re-reads the classNames sitting directly below it. It conveys nothing the code doesn't, and the moment the classes change (e.g. gray-75 -> gray-100) the prose is stale and misleading.
Objašnjenje (HR)
Good example
| 1 | // Width comes from the parent column so the card matches sibling widgets. |
| 2 | <div className="flex flex-col rounded-2xl border border-gray-100 bg-gray-25"> |
Explanation (EN)
The redundant description is dropped; the classNames are self-describing. The remaining comment explains a non-obvious constraint (where the width comes from) that the markup alone can't convey.
Objašnjenje (HR)