The rule “Math should not be performed on floats” is producing a lot of FPs.
Consider, an API expects a value as float like this.
API:
void doSomething(float f);
My code:
float f = 1f + 2f;
doSomething(f);
Since the API expects the value as float, I have little options, but to use floats myself. Ok, I could calculate in double and cast just to pass the value. But for what worth?
Another case is when the input values come in as floats. Example: FontMetrics.
float f1 = api.getValue1();
double result = f1 + 123.0; // FP (foreign value comes in as float.)
Firstly I would like to point out that this rule is not part of our default quality profile. This means that we do not recommend using this rule on all projects - in fact, it may make more sense for many users to leave it disabled. Rules that are not in the default quality profile generally receive less maintenance and are often less accurate in the general case.
That being said, I agree with you that sometimes there are operations where it will not make a difference whether you use float or double. Although just because a value comes from a method you have no control over directly, does not mean there cannot be an issue.
At the moment the rule’s implementation is very simple, it does not try to differentiate when a calculation is definitely safe and, unfortunately, that is not easy to do statically for the general case. Examples like 1f + 2f are good for illustration purposes but won’t bring much value to exclude, as this should be simplified to 3f in real code anyway. As soon as the values of the operation come from e.g. a method call, it becomes harder to impossible to know what they could be statically.
To summarize, right now this rule is not a priority to us and the solution to fix FPs not obvious. However, if you can provide a good use case for this rule and what value you get out of it from having it enabled, I will trigger further discussions internally. Otherwise, I would suggest disabling it in your quality profile.