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 hash small cache keys with crypto when a plain join works
Build cache keys from a sorted join, not SHA-1 — cheaper, collision-free, and debuggable. Hash only for length limits.
Bad example
| 1 | const hash = crypto |
| 2 | .createHash('sha1') |
| 3 | .update([...ids].sort((a, b) => a - b).join(',')) |
| 4 | .digest('hex'); |
| 5 | const cacheKey = `prices-${hash}`; // opaque, slower, harder to inspect |
Explanation (EN)
SHA-1 adds CPU cost and makes the key opaque, so you can't tell what a cache entry holds when debugging. For a short list of ids it buys nothing.
Objašnjenje (HR)
SHA-1 dodaje trosak procesora i cini kljuc neprozirnim, pa pri otklanjanju gresaka ne mozes vidjeti sto unos cachea sadrzi. Za kratku listu id-ova ne donosi nista.
Good example
| 1 | const cacheKey = `prices-${[...ids].sort((a, b) => a - b).join(',')}`; |
| 2 | // readable, fast, trivially inspectable in Redis |
Explanation (EN)
A sorted join is deterministic, free of collisions for distinct inputs, and lets you read the key contents directly when inspecting the cache.
Objašnjenje (HR)
Sortirani join je deterministicki, bez kolizija za razlicite ulaze, i omogucuje da izravno procitas sadrzaj kljuca pri pregledu cachea.
Exceptions / Tradeoffs (EN)
Use a hash when the joined key could exceed the store's key-length limit, or when the raw inputs are sensitive and shouldn't appear in keys/logs.
Iznimke / Tradeoffi (HR)
Koristi hash kada bi spojeni kljuc mogao premasiti ogranicenje duljine kljuca u pohrani, ili kada su sirovi ulazi osjetljivi i ne smiju se pojaviti u kljucevima/logovima.