-
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
Introduce Guava Preconditions
Refaster rules
#292
Conversation
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.
Very nice! Pushed a commit with some tweaks in line with "how we do it elsewhere", particularly in terms of naming.
The format string variants require special handling and are perhaps better deferred to another ticket (though I have some ideas around that; can write some stuff about that after the meetings I have now).
I would suggest also adding the other simple cases, though; don't mind doing those later :)
error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/PreconditionsRules.java
Outdated
Show resolved
Hide resolved
@BeforeTemplate | ||
void before(boolean condition, String message) { | ||
if (condition) { | ||
throw new IllegalArgumentException(message); | ||
} | ||
} |
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.
Opening a thread w/ @Stephan202's message:
The format string variants require special handling and are perhaps better deferred to another ticket (though I have some ideas around that; can write some stuff about that after the meetings I have now).
I also thought of leaving many of those as follow up. 👍
One thought on this however. Wouldn't e.g. a String#format()
call already partially be handled by the case I had pointed out here? As a result, we'd get
checkArgument(!condition, String.format(message, obj1));
which I'd then expect to be re-written by another Preconditions
rule. Curious to hear the thinking.
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.
Indeed! The philosophy of the Refaster rules defined in this repository are that they define the smallest/most generic possible improvement, so that in unison they improve the largest amount of code. So what you propose is the way to go.
There's one caveat here: not all String.format
calls can be replaced. What I suspect we need is a Matcher
that identifies valid Strings.lenientFormat
format strings; then we can instruct Refaster to rewrite only eligible expressions using @Matches(IsLenientFormatTemplateString.class)
. (Best name TBD.)
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.
^ It'll be more "scalable" to handle the String.format
logic as a BugChecker
, so let's defer that to a separate PR.
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 another commit.
@BeforeTemplate | ||
void before(boolean condition, String message) { | ||
if (condition) { | ||
throw new IllegalArgumentException(message); | ||
} | ||
} |
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.
Indeed! The philosophy of the Refaster rules defined in this repository are that they define the smallest/most generic possible improvement, so that in unison they improve the largest amount of code. So what you propose is the way to go.
There's one caveat here: not all String.format
calls can be replaced. What I suspect we need is a Matcher
that identifies valid Strings.lenientFormat
format strings; then we can instruct Refaster to rewrite only eligible expressions using @Matches(IsLenientFormatTemplateString.class)
. (Best name TBD.)
Latest commits LGTM @Stephan202, thanks 👍 |
error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/AssortedRules.java
Outdated
Show resolved
Hide resolved
946e517
to
0d6a33f
Compare
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.
Rebased and added one more commit.
Suggested commit message:
Introduce Guava `Preconditions` Refaster rules (#292)
@BeforeTemplate | ||
void before(boolean condition, String message) { | ||
if (condition) { | ||
throw new IllegalArgumentException(message); | ||
} | ||
} |
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.
^ It'll be more "scalable" to handle the String.format
logic as a BugChecker
, so let's defer that to a separate PR.
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 :)
import com.google.errorprone.refaster.annotation.UseImportPolicy; | ||
|
||
/** Refaster templates related to statements dealing with {@link Preconditions}. */ | ||
final class PreconditionsRules { |
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.
One more thing:
final class PreconditionsRules { | |
@OnlineDocumentation | |
final class PreconditionsRules { |
0b06825
to
8d65924
Compare
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.
@@ -41,6 +41,10 @@ int testCheckIndex() { | |||
return Objects.checkIndex(0, 1); | |||
} | |||
|
|||
void testCheckIndexConditional() { | |||
Objects.checkIndex(1, 2); |
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.
I think we should add a ImportPolicy
for CheckIndex
and CheckIndexConditional
as well.
- We do it for the
PreconditionsRules
as well. - We internally always prefer that as well.
- Even the
StaticImport
enforces this. However, as that is quite an opinionated check, some people will probably disable this check. Therefore it would be nice to make sure we use the static import for this as well.
Did you consider Java 9's |
Hello @JnRouvignac, yes for Up until now we haven't yet considered |
Something I just realized (and should have considered earlier): in a small number of cases the rules introduced here can cause functional or performance issues. See google/guava#5927 for an example of the former. An example of the latter would be a positional argument that is expensive to compute; such a computation now happens eagerly/unconditionally. It might be good to test these changes internally before the next tag. (There's no nice way to add a local |
This set of Guava
Preconditions
Refaster rules is non-exhaustive, but covers the most common use case for rewrites toPreconditions#check{Argument,State}()
.I had pointed these four use cases out during code review multiple times by now, so adding a rule already. 👍
These templates only affect simple
if
constructs, notif-else
. I think this should be part of another set of checks that removes theelse
-branch when theif
-branch's responsibility is only throwing an exception (or returning something).