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 add code comments unless truly necessary
Do not add explanatory code comments by default. Write self-documenting code (clear names, small functions) instead. Only add a comment when the code genuinely cannot express something on its own — a non-obvious 'why', a workaround, or a real gotcha.
Bad example
| 1 | expect(screen.queryByRole('img')).not.toBeInTheDocument(); // No broken <img> |
| 2 | expect(screen.getByText('K')).toBeInTheDocument(); // Initials placeholder shown |
Explanation (EN)
The comments just restate what the assertions already say — pure noise.
Objašnjenje (HR)
Good example
| 1 | expect(screen.queryByRole('img')).not.toBeInTheDocument(); |
| 2 | expect(screen.getByText('K')).toBeInTheDocument(); |
Explanation (EN)
Readable assertions need no comment.
Objašnjenje (HR)
Notes (EN)
Match the comment density of the surrounding code, which is usually near zero. Prefer renaming a variable or extracting a function over writing a comment. Reserve comments for genuinely non-obvious context that the code itself cannot convey.