Closed davidburstrom closed 3 years ago
It is highly unlikely that the autoboxing in return true
will have any measurable impact on performance/object allocation etc, so personally I would always use this more readable version, and not enable static analysis rules such as this.
Having said that, codebases and opinions differ, and there may be scenarios where the boxing does make a difference.
I'll take a look out at filtering mutatants of this form in the next release.
@mebigfatguy My apologies for roping you into this, but maybe you have some input on the performance benefits of the linter in question?
Released in 1.7.3
Thank you very much for addressing it so fast :)
This repo has 2 response times: 3 years or 3 days.
I think you decreased the average response time with this one :)
With Pitest 1.7.2:
Given
the
TRUE_RETURNS
mutator will produce the mutationwhich will always survive as the
true
will be auto-boxed to aBoolean
instance (unless we're testing Boolean instance identity, which seems pointless). The problem is that changing the production code to match the mutation is at odds with theNAB_NEEDLESS_BOOLEAN_CONSTANT_CONVERSION
bug type from fb-contrib (See http://fb-contrib.sourceforge.net/bugdescriptions.html).I might be missing some edge case here, but I think that the
TRUE_RETURNS
mutator shouldn't try to returntrue
in lieu ofBoolean.TRUE
, due to the auto-boxing. I'd be happy to understand if it is indeed a relevant case.The corresponding argument can be made for
FALSE_RETURNS
, of course.