Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Don't sacrifice readable multi-line objects to formatter one-lining
Keep object/type definitions multi-line when single-lining hurts readability; configure the formatter rather than letting it cram everything onto one line.
Bad example
| 1 | type TabDefinition = { name: string; queryParam: string }; |
Explanation (EN)
Crowding a complex shape onto one line can obscure its fields and relationships.
Objašnjenje (HR)
Good example
| 1 | type TabDefinition = { |
| 2 | name: string; |
| 3 | queryParam: string; |
| 4 | }; |
Explanation (EN)
Objašnjenje (HR)
Notes (EN)
Follow the repository formatter and prefer a multiline shape when it materially improves comprehension of a complex object or type.
Exceptions / Tradeoffs (EN)
Do not install personal formatter configuration in a company repository or fight a consistent formatter for a tiny object. Discuss a formatting-policy change separately.