Duplication & Complexity code review rules

Store repeated string literals in constants or variables to improve maintainability and reduce redundancy.

Identify cases where `x is None` or `x is not None` is used redundantly when `x` is always or never `None`. This may indicate a deeper logic issue.

Identify functions that return the same value regardless of input. This may indicate poor design or a logic error.

Remove unnecessary calls to `.toList()` when using the spread operator (`...`) as it is already designed to work with iterable collections.

Remove unnecessary `.toList()` calls when using the spread operator (`...`) to avoid redundant operations.

Provide a single permission check API (e.g., can(user, action, resource)) and reuse it across layers.

Copy-pasting code can lead to errors where getters or setters access the wrong fields. Always verify that properties interact with the expected fields.

In JS/TS workspaces, imports must use workspace package names (as defined in each package.json and exports) rather than relative paths crossing package boundaries.

Verify that LINQ queries are not excessively long. Break complex queries into smaller, more understandable expressions.

Detect deeply nested conditionals and suggest using guard clauses (`return unless condition`) instead to improve readability.

Ensure that methods perform a single, well-defined task. Large methods should be refactored into smaller, focused methods.

Check if the method, variable, or class title contains redundant context (e.g., using 'carDrive()' when 'drive()' would suffice). Ensure the title is concise and avoids repetition of surrounding context.

Ensure that explicit null checks are not used with `instanceof`, as `null` is never an instance of any class.

Identify overly defensive code that checks for unrealistic conditions, such as excessive `nil?` checks or redundant type verifications.

Route all analytics events through a single service/helper instead of calling the SDK directly from widgets and blocs.

Generate cache/Redis keys through a single utility with clear namespaces and versioning.

Define shared string literals (route names, keys, claim types) as constants/enums in a single place.

Ensure that multiple loops over the same collection are combined into a single loop to improve efficiency.

Deduplicate near-identical Dockerfiles by sharing a common base stage (multi-stage) and varying only service-specific steps via build args/targets.

Extract reusable SQL fragments/builders for commonly repeated WHERE/ORDER clauses.

Avoid maintaining multiple equivalent validators for the same shape; centralize checks in a single function/schema.

Provide a single updater that applies deltas/patches to messages rather than multiple ad-hoc updaters.

Merge near-duplicate methods into a single parameterized method or strategy.

Replace repeated set/get config calls with data-driven loops or loaders from a single schema/source.

Factor shared before_actions/filters/error handling into ApplicationController or a base controller.

For confirm/cancel flows, define common callbacks (confirm/cancel) once and reuse across dialogs.

Replace magic strings with constants or enums sealed classes; keep them in a single source of truth.

Create theme-like constants (radii, gaps, durations) and reuse across widgets.

Avoid duplicating runtime schemas and TypeScript types; derive types from constants/functions or declare as const tuples.

Ensure that libraries are not explicitly titled. Dart provides automatic library titles, so avoid redundant naming of libraries in the code.

Encapsulate coroutine parallelization (map async/awaitAll, limited concurrency) into utilities.

Factor repeated LINQ predicates/projections into reusable expressions or methods.

Factor repeated HTTP call setup/parsing/retry into a reusable helper or client.

Move repeated domain rules into reusable methods/services; keep controllers and handlers thin.

Move repeated domain calculations/transformations into named functions or service classes; keep controllers/scripts thin.

Move domain behavior from controllers/views into models or service objects.

When the same set of attribute/field names is used in multiple places (strong params, serializers, queries), extract it to a constant and reuse.

Factor common interaction/message handling into reusable functions or classes with parameters for the differing bits.

Duplicate sequences of statements must be extracted into a named function or utility.

Move repeated sequences of operations into named helpers or utilities and reuse them.

For HTTP/RPC handlers, parse+validate inputs in dedicated functions. Return typed errors and reuse across endpoints.

Factor identical widget trees or builders into private helpers or dedicated widgets.

Parameterize tool/runtime versions via ARGs (and CI build args) instead of hardcoding them across multiple Dockerfiles.

Define SQL strings as static final constants or in a repository, not inline across methods.

Centralize queue names and reuse across workers and tests.

Centralize validation in dedicated functions/objects and reuse; return typed errors.

Write functions and methods so each does one well-defined task. If a function handles distinct steps (validation, processing, saving, notifying), refactor into smaller focused functions.

Place cross-controller view helpers in ApplicationHelper (or a shared module) for reuse.

Add an 'Alternatives' section listing at least two plausible options with pros/cons and reasons for rejection.

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

Centralize repeated dialog creation/action handlers into a helper to ensure consistent UX and error handling.

Create factories/builders for repeated dialog/modal construction with configurable parameters.

Centralize repeated validation rules into helpers or small packages. Reuse them across handlers, services, and jobs.

Do not define the same method multiple times; consolidate behavior in one place.

Deduplicate identical queries within a request; reuse previously fetched data or preload in a single query.

Avoid no-op or duplicate calls (e.g., flatten.flatten, compact followed by compact!).

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

Compute expensive derived values once per input set and reuse them rather than recalculating in multiple places.

Extract repeated inline collections to unmodifiable static constants.