Readability & Refactor rules

Check for the use of getters and setters. These can introduce unexpected side effects and have limited compiler support. Recommend using regular methods unless required by a framework.

Detect occurrences of the comma operator in expressions. The comma operator can make code harder to read and debug, as it executes multiple expressions but only returns the value of the last one.

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

Detect the use of 'continue' inside loops. This practice can make control flow harder to follow. Recommend restructuring the loop for better readability.

Ensure that variables are declared as close as possible to their first use to improve readability.

Ensure that each variable is declared separately instead of using multiple declarations in one statement.

Always specify access levels (public, private, protected) when declaring class properties and methods. Don’t use the old `var` keyword for properties. Explicit visibility clarifies intent and prevents unintended access.

Avoid using the `goto` statement for flow control. Instead, refactor code using loops (for, while) and conditional structures (if/else, switch) for clear and maintainable logic.

Detect occurrences of the Array constructor. It behaves inconsistently depending on arguments. Recommend using array literals [] instead for clarity and predictability.

Ensure that the Object constructor is not used. Object literals are clearer, more predictable, and improve readability.

Check that fields and top-level variables are type-annotated explicitly when the type is not obvious from the context. This avoids ambiguity.

For async functions or functions returning Promise, document resolve value, rejection conditions, and usage with await; include @throws or @returns {Promise<Type>}.

Consider adding one empty line between multi-line properties (like complex `props`, `computed`, `methods`, `watch` objects) within the component options, especially in large components.

Check for the use of eval() to handle asynchronous execution. Eval leads to security vulnerabilities. Recommend using Async/Await or Promises instead.

Move complex domain calculations out of controllers/handlers into services or private helpers.

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

Move long/branchy UI decisions into named predicates or mappers to keep build methods simple.

Move long conditional expressions to well-named predicate methods.

Keep migrations readable by extracting multi-step data fixes to helper methods within the migration.

Move magic values (strings, thresholds, paths) to module-level constants with descriptive names.

Move domain-specific processing (validation, normalization, mapping) into cohesive services instead of scattering it across controllers/handlers.

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

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.