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 a null check for a case an existing success flag already rules out
Before adding an extra `=== undefined` guard alongside a `.success`/discriminant check, verify whether the failure branch already covers that case — a redundant condition just adds noise without changing behavior.
Bad example
| 1 | const validatedIdResult = validateType(Number(id), 'number'); |
| 2 | if (!validatedIdResult.success || validatedIdResult.data === undefined) { |
| 3 | return notFound(); |
| 4 | } |
Explanation (EN)
If the validator's contract guarantees `data` is defined whenever `success` is true, the `data === undefined` check can never be reached on its own — it's dead weight that just obscures the real condition.
Objašnjenje (HR)
Ako ugovor validatora jamci da je `data` definiran kad god je `success` true, provjera `data === undefined` nikad ne moze biti dosegnuta sama za sebe — to je mrtva tezina koja samo zamagljuje pravi uvjet.
Good example
| 1 | const validatedIdResult = validateType(Number(id), 'number'); |
| 2 | if (!validatedIdResult.success) { |
| 3 | return notFound(); |
| 4 | } |
Explanation (EN)
Trust the discriminated result type's contract; if in doubt, fix the validator's return type so `success: true` narrows `data` to always be defined instead of adding a runtime check that duplicates it.
Objašnjenje (HR)
Vjeruj ugovoru diskriminiranog tipa rezultata; ako sumnjas, popravi tip povrata validatora tako da `success: true` suzava `data` da uvijek bude definiran umjesto dodavanja runtime provjere koja to duplicira.