Skip to content

Add RedundantBooleanLiteralRefactor for Sonar rule java:S1125 - #162

Open
yashsiwacha wants to merge 1 commit into
alfasoftware:mainfrom
yashsiwacha:feature/s1125-redundant-boolean-literals
Open

yashsiwacha wants to merge 1 commit into
alfasoftware:mainfrom
yashsiwacha:feature/s1125-redundant-boolean-literals

Conversation

@yashsiwacha

Copy link
Copy Markdown

Implement RedundantBooleanLiteralRefactor in astra-core to automatically identify and remove redundant boolean literal comparisons (e.g. "bool == true" -> "bool", "bool != false" -> "bool", "bool == false" -> "! bool").

Uses JDT type binding resolution to safely verify that the non-literal operand is indeed a boolean type (either primitive or boxed Boolean) before transforming, ensuring type safety and preventing changes on custom classes.

Includes unit tests for all combinations of redundant comparisons (primitive and boxed types, reversed operand ordering, equals/not-equals operations), as well as positive/negative assertions.

Closes S1125

Implement RedundantBooleanLiteralRefactor in astra-core to automatically identify and remove redundant boolean literal comparisons (e.g. "bool == true" -> "bool", "bool != false" -> "bool", "bool == false" -> "! bool").

Uses JDT type binding resolution to safely verify that the non-literal operand is indeed a boolean type (either primitive or boxed Boolean) before transforming, ensuring type safety and preventing changes on custom classes.

Includes unit tests for all combinations of redundant comparisons (primitive and boxed types, reversed operand ordering, equals/not-equals operations), as well as positive/negative assertions.

Closes S1125

Signed-off-by: Yash Siwach <yashsiwach07@gmail.com>
@RadikalJin

RadikalJin commented Aug 20, 2026

Copy link
Copy Markdown
Member

Hi @yashsiwacha, and thank you for your contribution to Astra.

The overall shape of this looks great, as are the tests with before/after examples - exactly the pattern we like to see.

Before this can merge:

  • All current test examples use a plain boolean variable (bool). Could you add a case exercising a relational / instanceof expression for the negation? E.g. a > b == false, and x instanceof Foo == false.
  • I think the above may fail due to missing parentheses after negation. In rewrite, when negating we wrap the copied operand directly in a PrefixExpression without parenthesising it if needed. Since isBooleanExpression only checks the type of the operand and not its shape, this breaks when the operand is something like a relational or instanceof expression. For example:
    if (a > b == false) { ... }
    is valid Java (parses as (a > b) == false), but the refactor would currently rewrite this to
    if (!a > b) { ... }

Everything else looks good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants