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).
Keep API error response shapes consistent
Use one consistent JSON shape for the same class of error across all handlers so clients can parse responses uniformly.
Bad example
| 1 | // Handler A |
| 2 | return res.status(405).json({ success: false }); |
| 3 |
|
| 4 | // Handler B (same kind of error, different shape) |
| 5 | return res.status(405).json({ message: 'Method not allowed', status: 405 }); |
Explanation (EN)
Two handlers return different bodies for the same method-not-allowed error. Clients must special-case each endpoint to read the error.
Objašnjenje (HR)
Dva handlera vracaju razlicita tijela za istu method-not-allowed gresku. Klijenti moraju posebno obradivati svaki endpoint da procitaju gresku.
Good example
| 1 | // Shared shape everywhere |
| 2 | return res.status(405).json({ message: 'Method not allowed', status: 405 }); |
Explanation (EN)
Every handler returns the same { message, status } shape for the same error, so client code can handle errors generically.
Objašnjenje (HR)
Svaki handler vraca isti { message, status } oblik za istu gresku, pa klijentski kod moze obradivati greske genericki.
Notes (EN)
A shared error-response helper makes consistency automatic.
Bilješke (HR)
Zajednicki helper za error odgovore cini konzistentnost automatskom.