-
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 AssociativeMethodInvocation
check
#560
Conversation
Looks good. All 19 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
1 similar comment
Looks good. All 19 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
d99f65c
to
fc6263d
Compare
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
...ne-contrib/src/main/java/tech/picnic/errorprone/bugpatterns/AssociativeMethodInvocation.java
Show resolved
Hide resolved
c731b57
to
5ae92ab
Compare
fc6263d
to
485594e
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; PR now targets master
. Tnx for the review @oxkitsune 🙇
...ne-contrib/src/main/java/tech/picnic/errorprone/bugpatterns/AssociativeMethodInvocation.java
Show resolved
Hide resolved
Looks good. All 17 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
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 commit and some thoughts. PTAL 😄
@BugPattern( | ||
summary = | ||
"These methods implement an associative operation, so you can flatten the list of operands", | ||
link = BUG_PATTERNS_BASE_URL + "AssociativeOperatorUsage", |
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.
link = BUG_PATTERNS_BASE_URL + "AssociativeOperatorUsage", | |
link = BUG_PATTERNS_BASE_URL + "AssociativeMethodInvocation", |
AssociativeMethodInvocation
sounds like the better one indeed :).
implements MethodInvocationTreeMatcher { | ||
private static final long serialVersionUID = 1L; | ||
private static final Supplier<Type> ITERABLE = Suppliers.typeFromClass(Iterable.class); | ||
private static final ImmutableList<Matcher<ExpressionTree>> ASSOCIATIVE_OPERATIONS = |
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.
Technically speaking this could also be a ImmutableSet
right? Any reason for not doing so?
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.
Not really. Perhaps because these Matchers
don't implement a properly equality test anyway. But will change :)
|
||
@Override | ||
public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) { | ||
for (Matcher<ExpressionTree> matcher : ASSOCIATIVE_OPERATIONS) { |
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.
Should we start with the following if statement for fast return (tests still pass)?
if (tree.getArguments().isEmpty()) {
return Description.NO_MATCH;
}
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.
Pitest will flag it, but I agree 👍
* A {@link BugChecker} that flags unnecessarily nested usage of methods that implement an | ||
* associative operation. | ||
* | ||
* <p>The arguments to such methods can be flattened without affecting semantics, while making the |
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.
* <p>The arguments to such methods can be flattened without affecting semantics, while making the | |
* <p>The arguments of such methods can be flattened without affecting semantics, while making the |
Why is it "to" in this context, that doesn't sound right 🤔.
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 know that both forms are commonly used (with "of" being more prevalent), but IMHO "to" is better here: we're passing arguments to a method, and they aren't "owned" by the method.
@AutoService(BugChecker.class) | ||
@BugPattern( | ||
summary = | ||
"These methods implement an associative operation, so you can flatten the list of operands", |
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'm not really a fan of the "you" in this sentence. What about:
These methods implement an associative operation, so the list of operands can be flattened
It doesn't read as nice, but it avoids the term you 😋.
Looks good. All 17 mutations in this change were killed.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
5147ccd
to
e5c8d06
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 a commit. Tnx for the review!
* A {@link BugChecker} that flags unnecessarily nested usage of methods that implement an | ||
* associative operation. | ||
* | ||
* <p>The arguments to such methods can be flattened without affecting semantics, while making the |
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 know that both forms are commonly used (with "of" being more prevalent), but IMHO "to" is better here: we're passing arguments to a method, and they aren't "owned" by the method.
implements MethodInvocationTreeMatcher { | ||
private static final long serialVersionUID = 1L; | ||
private static final Supplier<Type> ITERABLE = Suppliers.typeFromClass(Iterable.class); | ||
private static final ImmutableList<Matcher<ExpressionTree>> ASSOCIATIVE_OPERATIONS = |
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.
Not really. Perhaps because these Matchers
don't implement a properly equality test anyway. But will change :)
|
||
@Override | ||
public Description matchMethodInvocation(MethodInvocationTree tree, VisitorState state) { | ||
for (Matcher<ExpressionTree> matcher : ASSOCIATIVE_OPERATIONS) { |
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.
Pitest will flag it, but I agree 👍
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
❗ This PR is on top of #561. ❗Suggested commit message:
This is in preparation for a bug checker that collapses multiple
@BeforeTemplate
methods into a singleRefaster.anyOf
method; such code changes may require flatting of nestedRefaster.anyOf
expressions; something taken care of by this check.