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).
Rename a configuration flag when its meaning changes
A flag whose behaviour is redefined but whose name is kept ends up implying the opposite of what it does, and the name is what people act on during an incident. Rename it in the same change that redefines it, and say so where it is documented.
Bad example
| 1 | # was: choose Redis instead of Memcached |
| 2 | # now: disable Redis in favour of an in-process map |
| 3 | USE_REDIS=false |
Explanation (EN)
The name still describes the old two-backend choice, so setting it now does close to the opposite of what a reader expects.
Objašnjenje (HR)
Ime i dalje opisuje stari izbor izmedu dvije pozadine, pa postavljanje sada radi gotovo suprotno od onoga sto citatelj ocekuje.
Good example
| 1 | # disables the shared cache and falls back to a per-process in-memory map |
| 2 | DISABLE_SHARED_CACHE=true |
Explanation (EN)
The name states the current behaviour, so nobody has to read the implementation to know what flipping it does.
Objašnjenje (HR)
Ime opisuje trenutno ponasanje, pa nitko ne mora citati implementaciju da bi znao sto se dogada kad ga promijeni.
Notes (EN)
Renaming an env var costs a deployment config change once. Leaving a misleading name costs every future reader, and worst at the moment someone is toggling it under pressure.
Bilješke (HR)
Preimenovanje varijable okoline jednom kosta izmjenu konfiguracije. Zavaravajuce ime kosta svakog buduceg citatelja, a najgore u trenutku kad ga netko mijenja pod pritiskom.