Python (Stack) code review rules

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.

Detect `except` clauses that use `or` or `and` to catch multiple exceptions. This does not work as intended. Recommend using a tuple of exceptions instead.

Identify instances where an exception object is created but never raised. This is likely an oversight and should either be removed or properly raised.

Ensure that `assert` is not used for validating user input or critical checks. Assertions can be disabled in optimized mode (`python -O`). Recommend using explicit validation with `if` conditions and raising proper exceptions.

Detect exception handling blocks that catch objects not derived from `BaseException`. This causes a `TypeError` and should be avoided.

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 `SystemExit` and `KeyboardInterrupt` are not caught without being re-raised. Preventing Python from exiting can cause unintended behavior.

Wrap HTTP/SDK calls with timeouts and catch transport/errors; log context and map to domain failures.

Validate presence, type, and range of critical inputs at boundaries (API, CLI, jobs) and fail fast with clear messages.

Log key operations with structured fields (actor/resource/operation) at appropriate levels; include exception info on failures.

Catch and handle only the exceptions you expect (e.g., KeyError, ValueError, TimeoutError); let unknown ones bubble.

Wrap multi-statement DB operations in a transaction; commit on success and rollback on any exception.

Enforce uniqueness at the database level (unique indexes/constraints) for identifiers and natural keys.

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

Detect function definitions that use mutable objects (lists, dictionaries) as default arguments. This can lead to unintended shared state. Recommend using `None` as the default and initializing the object inside the function.

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

Detect `except:` blocks that catch all exceptions indiscriminately. Using a broad `except:` can hide real issues and prevent necessary errors like `KeyboardInterrupt`. Recommend catching specific exceptions instead.

Identify function definitions where a mutable object (e.g., list, dictionary, set) is used as a default argument. This can cause shared state across function calls, leading to unintended behavior. Suggest using `None` as a default and initializing the object inside the function.

Identify global variables that are mutable (e.g., lists, dictionaries). Global mutable state can cause unpredictable behavior. Recommend using local variables or encapsulating state in a class.

Verify that after loading a PyTorch model, either `model.eval()` or `model.train()` is called. Failing to do so can result in incorrect behavior, especially for layers like dropout and batch normalization.

Identify functions that raise exceptions but do not document them in docstrings. Missing exception documentation makes it difficult to understand failure cases. Suggest adding an `:raises` section in the docstring.

Check if the `__all__` list in a module contains titles that are not defined. Listing undefined titles can cause `ImportError` when performing wildcard imports.

Verify that `__init__` methods always return `None`. Returning any other value causes a `TypeError` and prevents correct object instantiation.

Identify function calls where the number of arguments passed does not match the expected parameters. This often results in a `TypeError`. Suggest reviewing function signatures.

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

Verify that special methods (e.g., `__eq__`, `__len__`) have the correct number of parameters. Incorrect parameters can cause runtime errors or unexpected behavior.

Check if resources such as files or database connections are properly closed in a `finally` block. This ensures resources are always released, even if an exception occurs.

Guard file IO with try/except; handle OSError and data parse errors with clear messages.

Load and validate environment/config once during startup; inject settings into modules instead of re-reading env.

Check if memory allocation sizes are derived from untrusted input. Attackers may exploit this to crash the program or consume excessive resources. Recommend validating and limiting allocation sizes.

Detect code where resources (files, sockets, etc.) are not closed in a `finally` block. Using `finally` ensures that resources are released, even if an exception is raised.

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

Provide a decorator/context manager that opens/closes DB sessions and handles commit/rollback automatically.

Identify hot lookups/joins/sorts and add appropriate single/compound indexes in migrations.

Ensure that resources such as files, sockets, or database connections are managed using the `with` statement. Code that explicitly calls `.close()` without `with` should be refactored to use context managers for automatic resource cleanup.

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

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.

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.

Apply memoization (functools.lru_cache) or explicit caches for pure, expensive computations keyed by inputs.

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

Check for variables, functions, or classes that are used but not defined. This results in `NameError` and should be fixed by ensuring all symbols are properly declared.

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

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

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

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.

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

Expose constant dicts as read-only via MappingProxyType (or frozen dataclasses) to prevent runtime mutation.

Guard expensive debug log formatting behind level checks or lazy formatting.

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

Instantiate expensive clients (DB/HTTP/SDK) once and inject/reuse them; avoid per-call construction.

Use executemany/bulk operations and commit in sensible batches for large writes.

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.

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

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

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

Derive paths/URLs from configuration or environment variables, not string literals in code.

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

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

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.

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.

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.

Pass dependencies (clients, sessions, configs) into functions/classes instead of creating them internally.

When keys may be absent, prefer dict.get(key, default) or setdefault instead of direct indexing.

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.

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.

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