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 introduce a new synonym for a concept that already has an established name
When adding a new type/field, reuse the codebase's existing name for the concept (e.g. "article") instead of a new synonym (e.g. "story") — two names for the same thing invites confusion about whether they're actually different.
Bad example
| 1 | export interface FrontpageStory { |
| 2 | title: string; |
| 3 | url: string; |
| 4 | } |
Explanation (EN)
The codebase already has an established `Article`/`IArticle` concept; introducing `FrontpageStory` for what is functionally the same entity makes readers wonder whether a `Story` differs meaningfully from an `Article`.
Objašnjenje (HR)
Kod vec ima utvrden koncept `Article`/`IArticle`; uvodenje `FrontpageStory` za ono sto je funkcionalno isti entitet cini da se citatelji pitaju razlikuje li se `Story` znacajno od `Article`.
Good example
| 1 | export interface FrontpageArticleSummary { |
| 2 | title: string; |
| 3 | url: string; |
| 4 | } |
Explanation (EN)
Sticking to the established "article" vocabulary (with a qualifier describing the specific shape) keeps the domain model's terminology single-sourced.
Objašnjenje (HR)
Drzanje utvrdenog rjecnika "article" (s kvalifikatorom koji opisuje specifican oblik) drzi terminologiju domenskog modela jedinstvenom.