Code Quality

Code quality

Generated or edited code must follow the project's linting and formatting, DRY, KISS, functional programming principles, and clean-code practices.

Linting and formatting

• Conform to the lint and format config already in the repo (e.g. ESLint, Prettier).
• Do not introduce lint or style violations. Run the project's linter and formatter and fix any issues before considering the change complete.

DRY (Don't Repeat Yourself) — required

• Do not copy-paste blocks of logic or styles.
• Extract repeated values into constants, variables, tokens, mixins, or shared utilities.
• Reuse existing components, services, and helpers instead of duplicating behavior.

KISS (Keep It Simple, Stupid) — required

• Prefer the simplest solution that solves the problem; avoid over-engineering.
• Avoid unnecessary abstractions, layers, or indirection until they are justified by reuse or clarity.
• Prefer clear, readable code over clever or "elegant" code when they conflict.

Functional programming principles — required

• Prefer pure functions where possible: same inputs → same outputs, no side effects.
• Avoid mutable state; prefer immutable data and updates (e.g. new objects/arrays instead of mutating in place).
• Use declarative patterns: map, filter, reduce, and composition over imperative loops when they improve readability.
• Keep side effects (I/O, DOM, subscriptions) at the edges; isolate them in services or explicit effect boundaries.

Clean code — required

• Use full, descriptive names; avoid unnecessary abbreviations (unless a well-known project or domain term).
• Keep units of code focused and single-purpose; prefer small, reusable pieces.
• Avoid deep nesting and tangles; code should be easy to change without breaking unrelated behavior.
• Add brief comments or JSDoc for non-obvious behavior and document why when intent is not clear from the code alone.

Code style (Angular / TypeScript)

• Max ~30 lines per method — extract private helpers for anything longer.
• Max 3 parameters — use an options/config object beyond that.
• Use private on internal methods and fields.
• Single responsibility — one function does one thing.
• No business logic in components — delegate to stores/services.

TypeScript guidelines

• Prefer type inference where obvious; annotate return types on public methods and service APIs.
• Avoid any — use unknown and type-narrow.
• Define clear interfaces and types for component state, service responses, and data models. Co-locate in the feature folder or a shared models/ directory.
• No magic numbers/strings — extract to named constants or enums.
• No console.log in production code — use console.warn for caught errors only.

Source: swimlane/ngx-graph — distributed by TomeVault.