SONARJAVA-6090 Detect usage of io in rule S106

[rombirli]

No description provided.

[hashicorp-vault-sonar-prod]

SONARJAVA-6090

[asya-vorobeva]

Also makes sense to enrich rule description to mention IO.

[tomasz-tylenda-sonarsource]

LGTM, but please wait for Asya's review.

[asya-vorobeva]

I think we can remove in line 49 a check
tree instanceof MemberSelectExpressionTree mset. (which is always met)
Also please don't forget about updating metadata for the rule here.

[rombirli]

I think we can remove in line 49 a check
tree instanceof MemberSelectExpressionTree mset. (which is always met)

I’d prefer to keep this as is for a couple of reasons:

• Scope Creep: This change wasn't part of my PR; it was recently introduced by @tomasz-tylenda-sonarsource in b9dcc06. I'd like to keep the current PR changes minimal and focused.
• Best Practices: I find using pattern matching for instanceof to be a cleaner and safer way to handle variable casting compared to the traditional approach.

Since this is largely a matter of personal style preference and the code is already functional, can we leave it unchanged?

[rombirli]

Also please don't forget about updating metadata for the rule here.

done in aa43ca2

[asya-vorobeva]

I think we can remove in line 49 a check
tree instanceof MemberSelectExpressionTree mset. (which is always met)

I’d prefer to keep this as is for a couple of reasons:

• Scope Creep: This change wasn't part of my PR; it was recently introduced by @tomasz-tylenda-sonarsource in b9dcc06. I'd like to keep the current PR changes minimal and focused.
• Best Practices: I find using pattern matching for instanceof to be a cleaner and safer way to handle variable casting compared to the traditional approach.

Since this is largely a matter of personal style preference and the code is already functional, can we leave it unchanged?

As for me,

 else if (!isCompactSourceFile) {
      visitMemberSelectExpression((MemberSelectExpressionTree) tree);
 }

looks much more cleaner. But as you wish. (best practices are not dogmatic thing, depends on the situation)

About your first point, please believe me: it's much more better to leave the code in the file that you're working with better than before. Sort of cumulative changes, good way to fight with tech debt. :)

[asya-vorobeva]

LGTM

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
88.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube