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 rely on incidental repair to hide a data-loss bug
A dropped field masked by a later backfill process is still a bug worth fixing directly.
Bad example
| 1 | function mergeProfileData(dest: Profile, src: Profile): Profile { |
| 2 | return { |
| 3 | biography: dest.biography ?? src.biography, |
| 4 | education: dest.education ?? src.education, |
| 5 | // contactEmail is missing here; a later import happens to backfill it |
| 6 | // when it's null, so nobody notices in testing |
| 7 | }; |
| 8 | } |
Explanation (EN)
Because a separate import job fills the field back in later when it's empty, the bug doesn't look urgent — but until that job runs, the public-facing value is silently gone, and if the backfill job is ever removed or changed the bug becomes permanent with no warning.
Objašnjenje (HR)
Budući da zaseban uvozni posao kasnije popuni polje kad je prazno, greška ne izgleda hitno — no dok se taj posao ne pokrene, javno vidljiva vrijednost je tiho nestala, a ako se backfill posao ikad ukloni ili promijeni, greška postaje trajna bez ikakvog upozorenja.
Good example
| 1 | function mergeProfileData(dest: Profile, src: Profile): Profile { |
| 2 | return { |
| 3 | biography: dest.biography ?? src.biography, |
| 4 | education: dest.education ?? src.education, |
| 5 | contactEmail: dest.contactEmail ?? src.contactEmail, |
| 6 | }; |
| 7 | } |
Explanation (EN)
Fix the enumeration directly rather than trusting an unrelated process to paper over the gap; a future refactor that removes or changes the backfill job would otherwise turn a temporary glitch into permanent data loss.
Objašnjenje (HR)
Popravi nabrajanje izravno umjesto da se oslanjaš na nepovezan proces da prekrije prazninu; buduća refaktorizacija koja ukloni ili promijeni backfill posao inače bi pretvorila privremenu grešku u trajni gubitak podataka.