Rule cpp:S3659 "Alternative operators should not be used" should not apply to the boolean operators

Rules and Languages Report False-positive / False-negative...
, , ,
1

Hi, this is my first topic, and I am sorry if I selected the wrong category :worried:

This is the C++ rule which I call in question:

Alternative operators should not be used (cpp:S3659)

Even though the C++ standard defines both “Primary” and “Alternative” operators, it is not a good idea to use the alternatives. Developers seeing an alphabetical name expect a variable, a function, a class, a namespace… in short, anything but an operator, and they will be confused at best by code that uses such operators.

Primary Alternative
&& and
&= and_eq
& bitand
| bitor
~ compl
! not
!= not_eq
|| or
|= or_eq
^ xor
^= xor_eq

For the boolean operators, I think there are GOOD reasons why the alternative operators (not, and, or) should be used instead of the primary ones (!, &&, ||) :

  1. not, and, or are not confusing for people familiar with boolean logic (which every software developer should be).

  2. not, and, or are used in languages like python, which more and more C++ developers are familiar with.

  3. In C++, boolean operator ! is so short that the reader can miss it and misunderstand the code
    => using not solves that issue.

  4. In C++, boolean operator && can be confused with bitwise operator &
    => using and solves that issue.

  5. In C++, boolean operator || can be confused with bitwise operator |
    => using or solves that issue.

Thus I think that this rule should NOT apply to the 3 boolean operators.

If this is too controversial, then I suggest that the 3 boolean operators should at least have their own rule. That new rule could :

  • have a text explaining both the PROs and CONs ?
  • not be included in the “SonarWay” ?
  • have a lower default severity (currently: high) ?
3

Hello @cyril.og,

Sorry for the late reply – holidays season.

To start with I agree with you that this rule is subjective.

  • “SonarWay” is what makes sense for most codebases and based on our data from the many C++ projects that we analyze we can conclude that using not, and, or is not common in the C++ community. && || ! is the common practice. So this rule is here to enforce this common practice.

  • Now in your case, using not, and, or might make more sense and that is fine. it is just not a common practice in the C++ community and that why we don’t recommend using them. For the python argument, it is very subjective. You can make the opposite argument for other languages. For example, they are not part of the C standard(they were added as part of the standard library, not the language since C90).
    In the end, if you think your codebase is special and you see value in using these alternatives you can always disable the rule.

  • For the severity I totally agree with you, there is no reason for it to be high. I will update it.

Thanks,

1 Like
4

Thanks a lot, it was indeed to high for a subjective rule. :slight_smile:

5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.