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).
Drop comments that merely restate self-documenting code
If an expression or assertion already makes its intent obvious, don't add a comment that paraphrases it.
Bad example
| 1 | // Both requests must be signed |
| 2 | expect(signedRequests).toHaveLength(2); |
Explanation (EN)
The comment says nothing the assertion doesn't already say, so it's pure overhead that can drift out of sync with the code.
Objašnjenje (HR)
Komentar ne govori nista sto assertion vec ne kaze, pa je cisti visak koji se moze raziduliti s kodom.
Good example
| 1 | expect(signedRequests).toHaveLength(2); |
Explanation (EN)
Reserve comments for the non-obvious: why something is done, surprising edge cases, or constraints not visible in the code.
Objašnjenje (HR)
Komentare cuvaj za neocito: zasto se nesto radi, iznenadujuce rubne slucajeve ili ogranicenja koja se ne vide u kodu.
Exceptions / Tradeoffs (EN)
Keep comments that explain WHY, document a non-obvious format/invariant, or warn about a subtle gotcha. Balance against comment-the-why-for-edge-case-handling: drop the comment when the expression already makes its intent and reason self-evident.
Iznimke / Tradeoffi (HR)
Zadrzi komentare koji objasnjavaju ZASTO, dokumentiraju neociti format/invarijantu ili upozoravaju na suptilnu zamku.