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).
Preserve existing fallback semantics when refactoring a data source
Swapping a type/provider must keep the original `a ?? b` fallbacks unless a behavior change is intended and confirmed.
Bad example
| 1 | // before |
| 2 | get price() { return data.lastprice ?? data.closeprice1d; } |
| 3 | // after refactor to new provider |
| 4 | get price() { return data.price; } // closeprice1d fallback silently lost |
Explanation (EN)
Collapsing a two-source fallback into a single field during a 'mechanical' refactor changes runtime behavior when the primary value is absent — a silent regression.
Objašnjenje (HR)
Saimanje fallbacka iz dva izvora u jedno polje tijekom 'mehanickog' refaktora mijenja ponasanje u izvodenju kada primarna vrijednost nedostaje — tiha regresija.
Good example
| 1 | // keep the fallback in the new shape, or map it at the boundary |
| 2 | get price() { return data.price ?? data.previousClose; } |
| 3 | // if dropping it is intentional, call it out in the PR and confirm the source guarantees a value |
Explanation (EN)
Either carry the fallback into the new data shape, or explicitly confirm the new source always provides the value and document the deliberate behavior change.
Objašnjenje (HR)
Ili prenesi fallback u novi oblik podataka, ili izricito potvrdi da novi izvor uvijek daje vrijednost i dokumentiraj namjernu promjenu ponasanja.
Exceptions / Tradeoffs (EN)
No exception — if you intend to drop a fallback, that is a behavior change and should be stated and reviewed, not slipped in as a refactor. Balance against remove-dead-fallback-and-recovery-logic: keep a fallback when its failure mode still exists after the refactor; preserve behavior you can't prove is dead.
Iznimke / Tradeoffi (HR)
Bez iznimke — ako namjeravas ukloniti fallback, to je promjena ponasanja i treba je navesti i pregledati, a ne ubaciti kao refaktor.