Readability & Refactor 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.