Readability & Refactor rules

Replace repeated similar if/elif blocks with data-driven loops or dispatch tables.

Split long methods into cohesive private helpers with clear names and single responsibilities.

Break deep map/flatMap chains into named suspend functions or use runCatching/Result for clearer composition.

Avoid unnecessary AsQueryable/ToList/Where/Select chains that do nothing; keep pipelines minimal.

Avoid `!` when nullability is already proven or a safer alternative (`??`, early return) exists.

Eliminate assignments to variables that are never used or overwritten immediately to improve code efficiency and readability.

Function names must describe side effects and return values (e.g., fetchUser vs. process).

Give semantic names to magic numbers/strings and freeze where appropriate.

Prefer named def functions for non-trivial logic; keep lambdas only for tiny, inline expressions.

Extract numeric literals with meaning into named constants or readonly fields.

A method should return the same type in all code paths (e.g., always an array or always nil/record).

Complex computed properties should be split into as many simpler properties as possible.

Component templates should only include simple expressions, with more complex expressions refactored into computed properties or methods.

Detect unnecessary nesting where an if statement is the only statement inside an else block. Recommend using else-if instead for improved readability.

Use lowerCamelCase for parameters; prefer full, descriptive names over abbreviations.

When introducing or deprecating public APIs, include @since for introductions and @deprecated with migration notes and links for removals.

Check if `var` is used only when the variable type is clear and enhances readability. Avoid using `var` when the type is not obvious.

Use <inheritdoc/> to inherit docs for overrides/implementations, but explicitly add <exception> and behavior differences when applicable.

Alias imports when names overlap with locals or other modules; keep clear, unique identifiers.

Use the time package's types for handling time. For example, represent instants as `time.Time` and durations or time intervals as `time.Duration` instead of raw numeric types (int, int64).

Ensure that list, set, or dictionary comprehensions are not overly complex. If a comprehension includes multiple conditions or nested loops, recommend refactoring to a regular loop for better readability.

Ensure that exception variables in `rescue` blocks use meaningful titles instead of generic ones like `e`.

Choose names that reflect intent; avoid abbreviations except widely accepted ones.

Prefer intent-revealing names over cryptic abbreviations.