-
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
Enable the BugPatternNaming
check
#86
Conversation
4b51792
to
4dcec2a
Compare
4dcec2a
to
5887bbf
Compare
5887bbf
to
5bb5066
Compare
568bde6
to
9704cb2
Compare
1b187dd
to
8a89388
Compare
Rebased, resolved conflicts and applied the bug pattern to two new checks introduced since the PR was opened. |
Thoughts/opinions? :) |
That sounds like a good idea. Perhaps we can (re-)use parts of the structure from EP itself. For example a OTOH I think a simple split between Pushed a commit and rebased. |
8a89388
to
0feb610
Compare
@@ -192,7 +192,7 @@ ImmutableMap<K, V> after( | |||
|
|||
// XXX: Instead of `Map.Entry::getKey` we could also match `e -> e.getKey()`. But for some | |||
// reason Refaster doesn't handle that case. This doesn't matter if we roll out use of | |||
// `MethodReferenceUsageCheck`. Same observation applies to a lot of other Refaster checks. | |||
// `MethodReferenceUsageC`. Same observation applies to a lot of other Refaster checks. |
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.
Commenting to make sure I don't miss this.
private final CompilationTestHelper compilationTestHelper = | ||
CompilationTestHelper.newInstance(ExplicitEnumOrderingCheck.class, getClass()); | ||
CompilationTestHelper.newInstance(ExplicitEnumOrdering.class, getClass()); | ||
|
||
@Test | ||
void Identification() { |
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.
Let's sneak in this small rename.
void Identification() { | |
void identification() { |
0feb610
to
002354f
Compare
Rebased, resolved conflicts and added a commit to fix the build. |
As discussed offline, I moved the non- |
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.
Looks really nice :party-blob:!
Suggested commit message:
Or use something of this alternative:
|
Would go for the first option 👍 |
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.
This is very satisfying. Got two comments regarding class-naming/JavaDoc. PTAL :) First alternative suggested commit message LGTM (tweaked one word).
// XXX: Can we locate this code in a better place? Maybe contribute it upstream? | ||
final class Util { | ||
public final class Util { |
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. A util.Util
class doesn't look too great. In absence of much different functionality, should we for now make this something like TreeToStringConverter
with appropriate class JavaDoc?
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.
The operation is a static method, so and active word like "Converter" is not appropriate IMHO. Maybe Source
or SourceCode
? 🤔
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.
Changed it to SourceCode
and updated the class' JavaDoc. Feel free to revert or tweak 👍
/** A method invocation expression {@link Matcher} factory. */ | ||
// XXX: Document better. The expressions accepted here could also be defined using `MethodMatchers`. | ||
// So explain why this class is still useful. |
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.
With moving these to a util
subpackage and adding JavaDoc to them, I think fixing this XXX now is in order.
In lack of better ideas:
/** A method invocation expression {@link Matcher} factory. */ | |
// XXX: Document better. The expressions accepted here could also be defined using `MethodMatchers`. | |
// So explain why this class is still useful. | |
/** A factory for creating resuable Matchers. */ |
Also, this class could be fully static
and be more like a Util
class, 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.
Right, but I would like to keep this whole class exactly as-is: I have the feeling that this code is all-around very dodgy, and both things (the XXX
comment and the could-be-static observation make that clear). Improving this is out of scope.
Changes LGTM! Nice BugPattern and some good improvements to our setup 😄. |
ff6c7e3
to
2886734
Compare
Rebased and added a tiny tweak. Will merge once built. |
❗ This PR is on top of #76. ❗Open question: should we introduce a new subpackage for non-
BugChecker
utility classes, so that it's easier to keep an overview? Or should we organize the classes some other way?Suggested commit message (unless we introduce additional changes):