Style & Conventions code review rules

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

Detect uses of `re.sub()` where regular expressions are not needed. For simple string replacements, `str.replace()` is more efficient and should be used instead.

Ensure that factory method injection is used in `@Configuration` classes instead of `@Autowired` field injection.

Define constructors for `@immutable` classes as `const` to ensure that instances are created efficiently and cannot be modified.

Ensure that all control structures (if, for, while) use braces `{}` even for single statements.

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

Verify that API controllers inherit from `ControllerBase` instead of `Controller` unless views are explicitly required.

Never use `v-if` on the same element as `v-for`.

Detect the use of the 'any' type in TypeScript. Using 'any' disables type checking and can lead to runtime errors. Recommend using specific types or generics instead.

Ensure that `@Qualifier` is not used on `@Bean` methods, as explicit bean titles should be used instead.

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

Do not use constant patterns with type literals as it can lead to unexpected behavior. Prefer direct type checking 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.

Avoid assigning values to `void` variables as `void` is not a compatible type and doing so results in runtime errors.

Starting a route template with '/' in ASP.NET makes it absolute, ignoring controller-level routes and potentially breaking expected routing behavior.

Detect occurrences of the 'with' statement. This construct is banned in strict mode due to unpredictable behavior and makes debugging harder.

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).

Ensure that `@PathVariable` is used correctly in Spring applications to bind URI path variables to method parameters.

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.

Docstrings must match parameter names, optional defaults, return type, and raised exceptions; update the docstring in the same PR as any signature change.

Ensure that variables that never change are marked as `const` to prevent accidental modification and enhance code clarity.

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

Replace any/unknown with inferred generics, unions, or precise interfaces when the shape is known.

Ensure that all literal values passed to constructors of `@immutable` classes are marked as `const` to prevent unnecessary object creation.

Ensure that constants are declared with the `final` keyword to prevent modification.

Ensure that immutable instance fields are marked as `readonly`, and compile-time constants are marked as `const`.

For applications, styles in a top-level `App` component and in layout components may be global, but all other components should always be scoped. This can be achieved through CSS modules, class-based strategies like BEM, or the `scoped` attribute in Single-File Components.

In committed code, prop definitions should always be as detailed as possible, specifying at least type(s).

Ensure that Java records are used for immutable data structures instead of manually implementing immutable classes.

Throw and catch the most specific exception type available; avoid catching or throwing System.Exception unless rethrowing.

Make utility classes non-instantiable by providing a private constructor or marking them as `abstract`.

PR titles must follow the pattern: <scope>: <concise change summary>. Keep it under 72 characters and avoid vague words like 'stuff' or 'minor tweaks'.

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

Annotate function parameters and return types; use TypedDict/Protocol/Dataclass/Pydantic where appropriate.

Check for occurrences of var declarations. Using var leads to function scoping issues. Recommend using const for immutable values and let for mutable ones.

Ensure that strict equality (===) is used instead of loose equality (==). Loose equality can lead to unexpected type coercion and logical errors.

Detect the use of default exports. Named exports provide better clarity, maintainability, and prevent issues when refactoring.

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.

Detect unnecessary semicolons at the end of statements. Ruby does not require semicolons, so they should be removed unless multiple statements exist on the same line.

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.

Ensure that imports are explicitly listed and avoid using wildcard imports (`import package.*;`).

Base components (a.k.a. presentational, dumb, or pure components) that apply app-specific styling and conventions should all begin with a specific prefix, such as `Base`, `App`, or `V`.

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

Annotate fields/props to explicitly control persistence and serialization (e.g., transient/ignored fields).

Define a discriminated union or error class hierarchy and use user-defined type guards before handling specific cases.

Component names in JS/JSX should always be PascalCase, though they may be kebab-case inside strings for simpler applications that only use global component registration through `app.component`.

In most projects, component names should always be PascalCase in Single-File Components and string templates - but kebab-case in in-DOM templates.

Component options (like `name`, `props`, `data`, `computed`, `methods`, lifecycle hooks, etc.) should be ordered consistently according to a predefined sequence.

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.

Hoist constant Regex/Formatters/Collections into top-level vals or companion objects; avoid recreating in hot paths.

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.

Directive shorthands (`:` for `v-bind:`, `@` for `v-on:` and `#` for `v-slot`) should be used always or never.

Use `///` for documentation instead of block comments to improve tooling support and ensure better formatting in generated docs.

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.

Ensure that extensions use UpperCamelCase naming conventions (e.g., `MyExtension`). Avoid other casing styles that could reduce readability.

Check that import prefixes use lowercase_with_underscores (e.g., `my_library`), following Dart's style guide.

Ensure that identifiers such as variables and method titles are written in lowerCamelCase (e.g., `myVariable`). Avoid using other naming conventions.

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>}.

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

Ensure that parameters to `==` are non-nullable. Avoid using nullable parameters as they can introduce unexpected behavior and null reference errors.

Attributes within an element tag (including components) should be ordered consistently according to a predefined sequence (e.g., definitions, list rendering, conditionals, unique attributes, binding, events, content).

Avoid using element selectors (e.g., `button {... }`) directly within `<style scoped>`. Prefer class selectors.

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

At the top of your PHP files (before any code), declare `declare(strict_types=1)`. This forces PHP to enforce the declared parameter and return types strictly, avoiding automatic type coercion.

Check if attributes are consistently placed in the code, maintaining uniform formatting across the project.

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

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

Check if file titles follow the lowercase naming convention with underscores or dashes. This improves cross-platform compatibility and consistency.

Keep public types in files with matching names (one top-level type per file) to improve navigation.

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

Verify that method and variable titles follow `snake_case` conventions, avoiding camelCase or PascalCase.

Component names should prefer full words over abbreviations.

Use template helpers to set metadata.name and labels (app.kubernetes.io/) consistently across templates; prohibit hardcoded mismatches.

Use private fields with accessors; expose the narrowest visibility that satisfies usage.

Set sensible defaults for properties/fields or enforce via constructors.

Always initialize variables before use and avoid conditionally-defined locals.

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

Ensure that no line exceeds 100 characters in length to maintain readability.

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.

Ensure that annotations are placed consistently before or after modifiers throughout the codebase.

Default to private visibility; expose the minimal surface and prefer val with private set when mutation is needed.

Check if private or `file`-scoped classes that are never inherited are explicitly marked as `sealed` to indicate they are final.

Check if properties that are never reassigned are marked as readonly. This improves code clarity and prevents unintended reassignment.

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.

Component names should start with the highest-level (often most general) words and end with descriptive modifying words.

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

Prefer data providers for parameterized cases and use assertSame/assertNotSame for type-strict checks; avoid loose equals.

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

Use `const` for all references by default within Vue components (e.g., imports, non-reassigned variables, refs obtained via `ref()`). Use `let` only when reassignment of the variable itself is necessary (rare for state). Avoid `var` entirely.

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.

Check if type aliases are used instead of interfaces. Interfaces provide better extensibility and readability when defining object shapes.

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.

Prop names should always use camelCase during declaration. When used inside in-DOM templates, props should be kebab-cased. Single-File Components templates and JSX can use either kebab-case or camelCase props. Casing should be consistent.

Non-empty HTML attribute values should always be inside quotes (single or double, whichever is not used in JS).

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

Detect lines with trailing whitespace. Trailing spaces add unnecessary noise to version control diffs. Recommend removing them to keep the codebase clean.

Delete imports that are not referenced by the compilation unit.

Delete imports and locals that are not referenced; prefer tooling (ruff/flake8/mypy) to enforce.

Delete unused locals or prefix with underscore when required by interface.

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

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.

Use the standard logging module (or your app's logger) instead of print() in committed code.

When returning (T, error), return the zero value for T (or nil for pointers/slices/maps) whenever error != nil.

Components with no content should be self-closing in Single-File Components, string templates, and JSX - but never in in-DOM templates.

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

Filenames of Single-File Components should either be always PascalCase or always kebab-case.

The top-level tags (`<script>`, `<template>`, `<style>`) in Single-File Components (.vue files) should be ordered consistently across the project. A common convention is `<script>`, then `<template>`, then `<style>`.

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

When using iota to create enums (constant sets), start from 1 and use 0 as a 'zero value' meaning undefined or default. This way, an uninitialized variable of that enum type will not accidentally hold a valid value.

Child components that are tightly coupled with their parent should include the parent component name as a prefix.

Ensure that all overridden methods explicitly use the `@Override` annotation.

Use `///` instead of regular comments to properly document Dart classes, methods, and properties for automatic documentation generation.

Check if class and module titles use `CamelCase`. If not, suggest renaming them for consistency.

Replace `static final` with `const` where applicable to enable compile-time evaluation and optimize performance.

Identify occurrences where `== None` or `!= None` is used. Using `is None` and `is not None` is more reliable because it checks identity instead of equality, preventing potential issues with overloaded `__eq__` methods.

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

Detect relative imports (e.g., `from .module import x`). Relative imports can break if the project structure changes. Recommend using absolute imports (`from package.module import x`) for better clarity and maintainability.

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.

Error strings should start with a lowercase letter and not end with punctuation. They should state what went wrong in a concise, factual manner (for example, "file not found", not "File not found!").

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.

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.

Always use ES Modules (`import` and `export`) for managing dependencies and organizing code in Vue applications. Avoid non-standard module systems or global namespace pollution.

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

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.

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.

Utilize object method shorthands, property value shorthands, and computed property names when defining objects (e.g., in `data`, `computed`, `methods`). Prefer object spread syntax (`...`) over `Object.assign` for shallow copies or merging objects.

Consistent naming conventions improve readability and maintainability. Method and property titles should follow PascalCase.

Following PascalCase for type titles ensures consistency and readability across the codebase.

Prefer the most restrictive access modifier that works (private/internal) and expose only necessary members.

Follow .NET naming: PascalCase for types/methods/properties, camelCase for locals/parameters, and meaningful names.

Follow Rails conventions (plural resource routes, model singular class names, snake_case files).

Use the as operator or pattern matching for safe casts and guard null results before usage.

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.

Return appropriate status codes and prefer http.StatusText(status) (or a consistent JSON error schema) rather than inventing custom reason phrases.

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

Store and compare datetimes as timezone-aware (UTC). Convert to local time only at the edges (UI/IO).

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.

Utility classes are not meant to be instantiated. Mark them as static or provide a private constructor to prevent unintended instantiation.

Enforces consistent usage of hyphenated (kebab-case) or non-hyphenated (camelCase) attribute names on custom components in templates.

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