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).
Give similarly-named sibling parameters distinct, purpose-revealing names
When two options serve genuinely different roles but share a generic name pattern (e.g. homeName vs pageName), name them so the distinction is obvious, or add a one-line comment — don't leave a reviewer wondering if they can be merged.
Bad example
| 1 | interface MarketDataPageJsonLdOptions { |
| 2 | homeName?: string; |
| 3 | pageName: string; |
| 4 | } |
Explanation (EN)
Nothing in the names signals that `homeName` is the breadcrumb root label while `pageName` is the current page's breadcrumb label — a reviewer has to read the implementation to know they aren't redundant.
Objašnjenje (HR)
Nista u imenima ne signalizira da je `homeName` oznaka korijena breadcrumba dok je `pageName` oznaka trenutne stranice u breadcrumbu — recenzent mora procitati implementaciju da bi znao da nisu suvisni.
Good example
| 1 | interface MarketDataPageJsonLdOptions { |
| 2 | /** Breadcrumb root label (e.g. site/section home). */ |
| 3 | homeBreadcrumbName?: string; |
| 4 | /** Breadcrumb label for the current page. */ |
| 5 | pageBreadcrumbName: string; |
| 6 | } |
Explanation (EN)
Renaming to reflect the shared 'breadcrumb' role while keeping 'home' vs 'page' as the distinguishing word makes both the relationship and the difference clear at the call site.
Objašnjenje (HR)
Preimenovanje koje odrazava dijeljenu ulogu 'breadcrumb' uz zadrzavanje 'home' naspram 'page' kao rijeci koja razlikuje, cini jasnim i odnos i razliku na mjestu poziva.