For S1764, I can see there is some value to the checks other than the << operator.
For example, I have code that sends data to an SPI connected ADC, the channel number is requested with a 2 bit address in LSBits 4…3, so for channel 0 it’s (0 << 3), for channel 1 it’s (1 << 3), for channel 2 it’s (2 << 3) and for channel 3 it’s not allowed because who would ever want to do that??? Um, that would be me, as I want to use all 4 channels of the ADC, so (3 << 3).
Yes I could just write the hex directly, but then the code is less obvious.
I can’t actually think of a good example of a problem this is trying to fix, please share an example that makes sense.
Is there anyway to disable just the ‘a << a’ check?
Thanks for your feedback, I do agree with you that the rule description for rule S1764 needs a rework, and the good news is that Sonar is proactively reviewing and rewriting all the rule descriptions with a new format.
I created SONARJAVA-4558 to fix the rule in case of left-shift. The left-shift should be excluded by the rule because the result is not obvious, while the right-shift should still be reported since the result is always 0.
I think it’s worth mentioning that I found these issues while working with SonarLint in VS code, checking C source code, just in case the SonarJava issue does not cover the C language checker.
It’s of particular interest as we have recently got a license of SonarQube and I imagine before long we will not be able to push to repo’s when rule violations are detected.