SonarCloud remove candidate rule: java:S1611 Parentheses should be removed from a single lambda parameter when its type is inferred

[CDellaGiusta]

This poll closes Friday, April 18th 2025.

Candidate rule for removal: java:S1611
Number of issues with this rule in Uyuni: 102
Rule: Parentheses should be removed from a single lambda parameter when its type is inferred
Software qualities impacted: maintainability
Why is this an issue:

Lambda expressions with only one argument with an inferred type (i.e., no explicit type declaration) can be written without parentheses around that single parameter. This syntax is simpler, more compact and readable than using parentheses and is therefore preferred.
Noncompliant code example
(x) -> x * 2
Compliant solution
x -> x * 2

Should it be removed?:
A parenthesis around one parameter is not so noisy nor makes heavier the code to read. Possibly it could be not worth enforcing it to be fixed 102 times

All rule issues in Uyuni: https://sonarcloud.io/project/issues?languages=java&issueStatuses=OPEN%2CCONFIRMED&id=uyuni-project_uyuni&rules=java%3AS1611

Examples in our code:

see (pred) in:

  consume(
              predecessor,
              () -> insertFirstEnvironment(newEnv),
             (pred) -> appendEnvironment(newEnv, pred));

see (key) in:

private ExpectationsFunction SLES_EXPECTATIONS = (key) ->
            new Expectations() {{
                allowing(saltServiceMock).getSystemInfoFull(MINION_ID);
                will(returnValue(getSystemInfo(MINION_ID, null, key)));

[rjmateus]

This rule is marked as Low severity in sonarcloud. It's more related to code style/maintainability. Since it's marked as low severity, I would vote to keep it.

[CDellaGiusta]

This rule is marked as Low severity in sonarcloud. It's more related to code style/maintainability. Since it's marked as low severity, I would vote to keep it.

Please keep in mind it's not about severity, it's about going to fix it sooner or later. We should in theory come to a situation with "0 errors 0 warnings", so if a rule it's worth keeping, then all the occurrences should "sooner or later" be fixed. There is no point to keep a rule and never fix it: you may have tons of errors/warnings that do not catch your attention, and hence some important things may slip in the cracks.
As you said, this rule is more about "style" and personally I don't mind about an additional set of parentheses (it makes intention clearer). So I would vote to remove it, to avoid a fix not worth doing IMHO