Would it be possible to configure 'aggressivity' of SA1407 some how?
It's nice rule, but we're not using it now because of its excessive agressivity.
Some examples where the precedence is obvious and required bracket makes only cluter:
a * b + c
a * b + c * d
a + b / c
versus
(a * b) + c
(a * b) + (c * d)
a + (b / c)
I'm undecided yet on this, but I think it will be quite difficult to get a consistent set of rules that determine when parenthesis are required or not, especially since this rule is also about catching potential bugs.
For example:
a * b + c could have been intended to be a * (b + c), but the developer made a mistake here.
After quick look at code of SA1407 it occurred to me that maybe you can configure it in way you would be able to relax behaviour of SA1407ArithmeticExpressionsMustDeclarePrecedence.IsSameFamilyMethod.
For example you could say in configuration that '*' and '+' are in same family.
I agree that in some places the precedence is clear. How would a configuration option look like? How would I express that '+' and '*' are in the same family?
Currently I am in favor of leaving the rule as-is. I might change my mind if someone posted a very specific proposal with rationale, but this request in its current form seems to raise more questions than it answers.
:-1: I think the point of the rule is that a programmer doesn't need to count on the order of precedence of operators in C#. When I did C programming, I kept a little chart on the precedence of the various operators taped to my monitor so I could figure out what was actually happening with some of the more complex C statements written by other people. With this rule in place, there is no need for a chart like that. Remember that unsafe code is almost C.
Of course, if a statement only has * and + in it, most people know the order, but I think it still makes the code more clear. I also makes it really clear what the programmer who wrote the code intended.
It looks like this is a wontfix based on the current responses.
Most helpful comment
It looks like this is a wontfix based on the current responses.