Rules Hub
Code Ruleset
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Avoid comments explaining self-evident language features
Don't add comments explaining well-known language idioms like type-only imports; they add noise, not clarity.
Bad example
| 1 | // This is a type-only import. |
| 2 | import type { ChartOptions } from 'charting-lib'; |
Explanation (EN)
Defining a routine type-only import adds no information beyond the syntax.
Objašnjenje (HR)
Objašnjenje rutinskog type-only importa ne dodaje ništa što sama sintaksa već ne pokazuje.
Good example
| 1 | import type { ChartOptions } from 'charting-lib'; |
Explanation (EN)
The syntax already identifies the import as type-only.
Objašnjenje (HR)
Sintaksa već označava da import služi samo za tipove.
Notes (EN)
Remove comments that merely define syntax already clear to the intended maintainers; preserve concise rationale for a non-obvious constraint or workaround.
Bilješke (HR)
Ukloni komentare koji samo opisuju očitu sintaksu. Sačuvaj kratko obrazloženje nejasnog ograničenja ili nužnog zaobilaznog rješenja.
Exceptions / Tradeoffs (EN)
Fine to add a short comment if the type-only import exists specifically to preserve a non-obvious optimization (e.g. keeping a heavy library out of a particular bundle) that isn't visible from the import alone — but keep it to the non-obvious part, not a definition of what 'import type' does. A comment explaining why an import must remain type-only to protect a lazy bundle boundary can be useful and falls under the existing exception.
Iznimke / Tradeoffi (HR)
Kratki komentar ima smisla ako type-only import čuva neočitu granicu paketa, primjerice sprječava uključivanje velike biblioteke u glavni bundle. Objasni to ograničenje, a ne značenje sintakse import type.