-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prefer BigDecimal.valueOf(double)
over new BigDecimal(double)
#394
Conversation
cc81eb8
to
6f11b4c
Compare
This comment was marked as outdated.
This comment was marked as outdated.
6f11b4c
to
346407b
Compare
/** Prefer {@link BigDecimal#valueOf(long)} over the associated constructor. */ | ||
// XXX: Ideally we'd also rewrite `BigDecimal.valueOf("<some-integer-value>")`, but it doesn't | ||
/** Prefer {@link BigDecimal#valueOf(double)} over the associated constructor. */ | ||
// XXX: Ideally we'd also rewrite `new BigDecimal("<some-integer-value>")`, but it doesn't |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
think this was meant here; not sure if this is a nice comment to keep around anyway, but I'll leave that up to you 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I wonder whether the comment meant a bit of both: if "<some-integer-value>"
represents a value that can be expressed as a long
, then passing in a long
/int
is nicer than a string. (But such a change can't be done using Refaster; it'd require a BugChecker
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see that BigDecimal.valueOf
doesn't exist. So certainly that was not meant 😄
Looks good. No mutations were possible for these changes. |
@@ -18,6 +18,6 @@ ImmutableSet<BigDecimal> testBigDecimalTen() { | |||
} | |||
|
|||
ImmutableSet<BigDecimal> testBigDecimalFactoryMethod() { | |||
return ImmutableSet.of(new BigDecimal(0), new BigDecimal(0L)); | |||
return ImmutableSet.of(new BigDecimal(2), new BigDecimal(2L), new BigDecimal(2.0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
felt 2
was a nicer value to use here as there is a rule above to rewrite 0
to ZERO
as well
also did not include 2F
because there is no explicit BigDecimal(float)
constructor, whilst there are separate ones for int
, long
and double
; in this sense you could actually consider dropping the integer valueOf
s in the existing tests above because they just map to the valueOf(long)
anyway (there is no explicit int
version).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one @Venorcis! I'll circle back later for a full review :)
/** Prefer {@link BigDecimal#valueOf(long)} over the associated constructor. */ | ||
// XXX: Ideally we'd also rewrite `BigDecimal.valueOf("<some-integer-value>")`, but it doesn't | ||
/** Prefer {@link BigDecimal#valueOf(double)} over the associated constructor. */ | ||
// XXX: Ideally we'd also rewrite `new BigDecimal("<some-integer-value>")`, but it doesn't |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I wonder whether the comment meant a bit of both: if "<some-integer-value>"
represents a value that can be expressed as a long
, then passing in a long
/int
is nicer than a string. (But such a change can't be done using Refaster; it'd require a BugChecker
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a small commit. Have a meeting now; will finalize review afterwards :)
/** Prefer {@link BigDecimal#valueOf(long)} over the associated constructor. */ | ||
// XXX: Ideally we'd also rewrite `BigDecimal.valueOf("<some-integer-value>")`, but it doesn't | ||
/** Prefer {@link BigDecimal#valueOf(double)} over the associated constructor. */ | ||
// XXX: Ideally we'd also rewrite `new BigDecimal("<some-integer-value>")`, but it doesn't |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see that BigDecimal.valueOf
doesn't exist. So certainly that was not meant 😄
Looks good. No mutations were possible for these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added one more commit. Suggested commit message:
Prefer `BigDecimal.valueOf(double)` over `new BigDecimal(double)` (#394)
See https://rules.sonarsource.com/java/RSPEC-2111
/** Prefer {@link BigDecimal#valueOf(double)} over the associated constructor. */ | ||
// XXX: Ideally we also rewrite `new BigDecimal("<some-integer-value>")` in cases where the | ||
// specified number can be represented as an `int` or `long`, but that requires a custom | ||
// `BugChecker`. | ||
static final class BigDecimalFactoryMethod { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we're here, let's rename this rule in line with our current naming strategy.
static final class BigDecimalFactoryMethod { | |
static final class BigDecimalValueOf { |
cc3af0f
to
dce6db6
Compare
Looks good. No mutations were possible for these changes. |
1 similar comment
Looks good. No mutations were possible for these changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch @Venorcis 🚀 !
new BigDecimal(...)
to doublesBigDecimal.valueOf(double)
over new BigDecimal(double)
A very nice rule to rewrite
new BigDecimal(long/int)
toBigDecimal.valueOf(long/int)
already existed. As usingnew BigDecimal(double)
is quite discouraged, this PR extends the existing rule to rewritenew BigDecimal(double/long/int)
toBigDecimal.valueOf(double/long/int)