Readability & Refactor code review rules

Detect methods that have an empty body. If a method is empty, ensure that a comment is present explaining why it remains unimplemented.

Check if loops use equality operators (== or !=) in termination conditions. These can lead to infinite loops if the condition is never met exactly. Instead, use relational operators like < or > for safer loop termination.

Ensure that relational operators (`<`, `>`) are used instead of equality operators (`==`, `!=`) in loop termination conditions.

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.

Returning null from a Task or Task<T> method causes a NullReferenceException if awaited. Use Task.CompletedTask or Task.FromResult<T>(null) instead.

Check if every `case` statement includes an `else` clause. If an `else` clause is missing, ensure that a comment explicitly states why it is unnecessary.

Verify that all `if...elsif` constructs include a final `else` clause. If `else` is missing, ensure there is a comment explaining why all cases are covered.

Use curly braces `{}` around all control structures (`if`, `for`, `while`, `do`-`while`) to improve readability and prevent logic errors.

Using `new Guid()` instead of `Guid.Empty` or `Guid.NewGuid()` can be misleading and lead to unintended behavior.

Do not use `return`, `break`, or `continue` inside `finally` blocks as they can suppress exceptions and lead to unintended behavior.

Ensure that constructors do not include asynchronous operations. Constructors should initialize class instances synchronously. If async logic is required, suggest moving it to a separate initialization method.

Detect missing commas in lists, tuples, or dictionaries that unintentionally concatenate strings. This can lead to unexpected behavior and hard-to-find bugs.

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

Do not combine mechanical changes (formatting, renames) with behavioral changes. If unavoidable, separate commits and call out which commits are mechanical.

Check if `goto` statements are avoided. Ensure that structured control flow statements (`if`, `for`, `while`) are used instead.

Detect occurrences of the comma operator in expressions. The comma operator can make code harder to read and debug, as it executes two expressions but only returns the last one. Suggest alternative structures for better readability.

Check for empty code blocks (such as `if` or `loop` structures) that do not contain any statements. If an empty block is present, ensure it includes a comment explaining its purpose.

Every package must have a package comment, and each exported identifier must have a comment starting with the identifier name and a full-sentence summary.

All public modules, classes, and functions must include a docstring immediately after the definition, using PEP 257 conventions (one-line summary + optional sections like Args, Returns, Raises).

When a function is unsafe, may panic, or returns Result, include sections # Safety, # Panics, and/or error conditions in the docs.

Never compare the address of a variable to nil (e.g., `&x == nil`). To check if a pointer is nil, compare the pointer itself to nil. The address of a variable (`&x`) will always be non-nil if `x` exists.

Detect functions that mix `return` statements with values and those without. Inconsistent return usage can lead to unpredictable behavior.

Verify that method parameters in overrides and interface implementations match the base method’s parameter titles to maintain consistency.

All public classes, interfaces, and methods must include Javadoc with a summary sentence, @param for each parameter, @return when not void, and @throws where applicable.

All exported JS/TS functions, classes, and public members must include JSDoc with a summary and @param/@returns; include @throws when applicable.

Prefer Server Components for pages/layouts and move interactivity to small leaf Client Components. Only add 'use client' where browser APIs or event handlers are strictly necessary.

Ensure that lambda expressions remain short and simple. If a lambda grows too complex, refactor it into a titled method.

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

Use `for` elements inside map literals instead of `Map.fromIterable` to improve readability and allow better compiler optimizations.

Use `is!` instead of `!is` for type checking to prevent confusion and ensure consistent behavior.

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

Check if React children are passed as regular props instead of being nested inside components. Passing them incorrectly can cause conflicts and reduce clarity.

Identify function parameters that are declared but never used within the function body. Remove them to improve clarity and maintainability.

Avoid the !! operator. Prefer safe calls, Elvis (?:), early returns, or explicit exceptions with a clear message.

If the PR is large (many files/lines), split it into logical chunks or provide a clear justification and review guide listing file groups and what to focus on.

Keep UI/controllers thin; move domain logic to services or domain objects.

Calling synchronous methods inside async code can block execution and reduce performance. Use awaitable methods to ensure proper async execution.

All public types and members must have XML documentation comments with <summary>, <param>, <returns> (if non-void), and <exception> when thrown.

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

Ensure that titlespace structures are not overly deep. Favor a flat, organized structure to enhance readability and navigation.

Treat function inputs as immutable; copy before mutation (e.g., dict.copy(), list(x)).

Ensure that large classes with multiple responsibilities are refactored into smaller, more manageable classes.

Identify lambda functions that are too complex. Lambdas should be simple and concise. If a lambda contains multiple expressions, recommend converting it to a titled function for better readability.

Never use a pointer to an interface type. Pass interfaces as values, since an interface already provides reference semantics to the underlying data.

Do not use pointers to slice or map types. Slices and maps are already reference types that point to underlying data, so they can be passed by value and still allow modifications to the contents.

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.

Check if semicolons are used at the end of statements in Python code. Semicolons are unnecessary and may cause readability issues or errors when multiple statements are placed on one line. Recommend using new lines instead.

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

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.

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

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

Replace raw numeric/string literals used for dimensions, durations, and thresholds with named constants.

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

The first sentence should be a standalone summary used by godoc. For functions returning error, state error conditions succinctly.

Use distinct variable names across scopes; never reuse the outer loop variable in inner loops or comprehensions.

Component names should prefer full words over abbreviations.

Replace long parameter lists with request objects or records; validate them as a unit.

Detect `try` blocks that contain excessive code. Large `try` blocks make it harder to debug errors. Recommend narrowing the scope of the `try` block to only the necessary code.

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.

Check if lines exceed 80 characters (excluding comments and docstrings). Long lines reduce readability. Recommend breaking lines or using line continuations for better formatting.

Detect lines exceeding 120 characters and suggest breaking them into multiple lines for better readability.

Ensure that lines do not exceed 80 characters. Long lines reduce readability, especially on smaller screens or during code reviews.

Store long static templates/prompts in files and load them at runtime; avoid embedding huge multi-line strings in code.

Elements with multiple attributes should span multiple lines, with one attribute per line.

Ensure that multiple variables are not declared in a single statement. This practice reduces readability and can introduce subtle bugs. Recommend declaring variables separately.

Check if class members are grouped by accessibility (`public`, `protected`, `private`) to improve code readability and maintainability.

Ensure that multiple statements are not written on the same line. Each statement should be placed on a new line to improve readability.

Ensure that non-boolean properties or variables are titled with noun phrases (e.g., `userDetails`, not `getUserDetails`). This improves readability.

Use arrow functions (`=>`) for anonymous functions like callbacks (e.g., in lifecycle hooks, watchers, event handlers, array methods) instead of the `function` keyword, especially when needing lexical `this`.

Detect string formatting using `.format()` or `%`. These methods are less readable and slower than f-strings. Recommend converting string formatting to f-strings for better readability and performance.

Ensure that titled classes are used instead of untitled tuples for complex data structures. Tuples should only be used when their purpose is immediately clear.

Use strict comparison operators (=== and !==) instead of loose (== and !=) in most cases. Strict comparisons check both type and value, avoiding PHP’s implicit type coercion pitfalls.

Check for functions with unused parameters and ensure they are titled with `_` or `__` to indicate they are intentionally unused.

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.

Ensure that destructuring is used in function parameters where applicable. This improves readability by clearly showing accessed properties and default values.

Use object and array destructuring to access properties from objects (like `props`, `this`, context in `setup`) or elements from arrays, especially when accessing multiple items.

Validate and return early to reduce nesting and improve readability.

When a value comes from a finite set, model it as an enum constant instead of string/int literals.

Replace string literals that represent finite sets with enums (optionally flagged) or constants.

Ensure that simple methods and properties use expression-bodied syntax to improve code conciseness and readability.

Validate and return early to avoid deep nesting.

Use safe calls (?.), the Elvis operator (?:), let/run/also for scoped handling, and early returns for invalid input.

Document public items with /// and modules/crates with //!; include minimal runnable examples that pass doctests where applicable.

Prefer comprehensions over map/filter chains and avoid double-sorting or sorting inside loops.

Check if the code imports individual classes or functions instead of the entire module. Directly importing specific classes or functions can clutter the titlespace and increase naming conflicts. Recommend importing the module and referencing items explicitly.

Replace numeric/string literals with named constants to document meaning.

Prefer redirect() and notFound() over manual 302/404 handling and custom components in App Router.

Ensure that arithmetic and logical operators have spaces around them for better readability (e.g., `x + y` instead of `x+y`).

Prefer precise types (long, BigDecimal, LocalDate) over Number/Object when the domain is known.

Prefer Struct (or value objects) over OpenStruct for performance and type clarity.

Check for cases of string concatenation using +. Template literals improve readability and are less error-prone.

Check if function signatures include type annotations. Type hints improve readability and help catch type-related errors early. Recommend adding type annotations where missing.

Ensure that functions in public APIs include type annotations. Type annotations improve code clarity and help catch type-related errors early. Recommend adding them where missing.

Add scalar/union/nullable type hints and return types to functions, methods, and properties; prefer interfaces over mixed.

Detect multiple statements on the same line, separated by semicolons. This reduces readability and debugging efficiency. Recommend placing each statement on its own line.