SonarCloud remove candidate rule: java:S1066 Mergeable "if" statements should be combined

[CDellaGiusta]

This poll closes Friday, April 18th 2025.

Candidate rule for removal: java:S1066
Number of issues with this rule in Uyuni: 66
Rule: Mergeable "if" statements should be combined
Software qualities impacted: MAINTAINABILITY
Why is this an issue:

Nested code - blocks of code inside blocks of code - is eventually necessary, but increases complexity. This is why keeping the code as flat as possible, by avoiding unnecessary nesting, is considered a good practice.

Merging if statements when possible will decrease the nesting of the code and improve its readability.

Code like

if (condition1) {
 if (condition2) {             // Noncompliant
   /* ... */
 }
}

Will be more readable as

if (condition1 && condition2) { // Compliant
 /* ... */
}

Should it be removed?:
There could be times when some "if" statements could be nested for readability reasons, or to explicitly mark the programmer's intention.

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

Examples in our code:

 private void syncObjectToSet(Set set, Object obj) {
      if (obj instanceof Selectable next) {
          if (next.isSelectable()) {
              if (set.contains(next.getSelectionKey())) {
                          next.setSelected(true);
              }
          }
      }

for (Object oIn : result) {
          ChannelTreeNode item = (ChannelTreeNode) oIn;
          if (item.getName() != null) {
              if (item.getName().equals(channel.getName())) {
                  foundChannel = true;
                  break;
              }
          }
      }
     

[rjmateus]

I don't we should enforce it, since it can make sense to make the code easier to read. Another option could be to reduce the severity for this rule from medium to low.

[cbosdo]

If IntelliJ has a auto refactoring code that does this reliably for us I'm OK to keep the rule and fix them all as it makes code a bit easier to read. But if fixing it is a pain, then let's remove it