Skip to content
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

Merged
merged 6 commits into from
Aug 7, 2022

Conversation

Stephan202
Copy link
Member

@Stephan202 Stephan202 commented Apr 25, 2022

❗ 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):

Enable the `BugPatternNaming` check (#86)

@rickie rickie self-requested a review May 16, 2022 08:37
@Stephan202 Stephan202 force-pushed the renovate/version.error-prone-orig branch 2 times, most recently from 4b51792 to 4dcec2a Compare June 6, 2022 07:13
@rickie rickie force-pushed the renovate/version.error-prone-orig branch from 4dcec2a to 5887bbf Compare June 17, 2022 17:39
@rickie rickie force-pushed the renovate/version.error-prone-orig branch from 5887bbf to 5bb5066 Compare July 6, 2022 11:52
@Stephan202 Stephan202 force-pushed the renovate/version.error-prone-orig branch from 568bde6 to 9704cb2 Compare July 31, 2022 12:34
Base automatically changed from renovate/version.error-prone-orig to master July 31, 2022 13:50
@Stephan202 Stephan202 force-pushed the sschroevers/enable-BugPatternNaming-check branch from 1b187dd to 8a89388 Compare August 1, 2022 19:12
@Stephan202
Copy link
Member Author

Rebased, resolved conflicts and applied the bug pattern to two new checks introduced since the PR was opened.

@Stephan202
Copy link
Member Author

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?

Thoughts/opinions? :)

@rickie
Copy link
Member

rickie commented Aug 2, 2022

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?

That sounds like a good idea. Perhaps we can (re-)use parts of the structure from EP itself. For example a matchers and util subpackage.

OTOH I think a simple split between BugCheckers and the rest is fine for now. WDYT?

Pushed a commit and rebased.

@rickie rickie force-pushed the sschroevers/enable-BugPatternNaming-check branch from 8a89388 to 0feb610 Compare August 2, 2022 09:54
@@ -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.
Copy link
Member

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() {
Copy link
Member

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.

Suggested change
void Identification() {
void identification() {

@Stephan202 Stephan202 force-pushed the sschroevers/enable-BugPatternNaming-check branch from 0feb610 to 002354f Compare August 4, 2022 10:03
@Stephan202
Copy link
Member Author

Rebased, resolved conflicts and added a commit to fix the build.

@Stephan202
Copy link
Member Author

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?

As discussed offline, I moved the non-BugChecker classes to a .util subpackage. Did require me to document now-public methods. The PR is now ready for review.

@Stephan202 Stephan202 marked this pull request as ready for review August 4, 2022 11:31
@Stephan202 Stephan202 requested a review from Badbond August 4, 2022 11:31
@Stephan202 Stephan202 added this to the 0.1.0 milestone Aug 4, 2022
Copy link
Member

@rickie rickie left a 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:!

@rickie
Copy link
Member

rickie commented Aug 4, 2022

Suggested commit message:

Enable the `BugPatternNaming` check (#86)

While there, introduce a `.util` subpackage for non-`Bugchecker` classes.

Or use something of this alternative:

Introduce a `.util` subpackage in `errorprone.bugpatterns` for non-`Bugchecker` classes.

@Stephan202
Copy link
Member Author

Would go for the first option 👍

Copy link
Member

@Badbond Badbond left a 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 {
Copy link
Member

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?

Copy link
Member Author

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? 🤔

Copy link
Member

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 👍

Comment on lines 15 to 17
/** 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.
Copy link
Member

@Badbond Badbond Aug 4, 2022

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:

Suggested change
/** 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?

Copy link
Member Author

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.

@rickie
Copy link
Member

rickie commented Aug 5, 2022

Changes LGTM! Nice BugPattern and some good improvements to our setup 😄.

@Stephan202 Stephan202 force-pushed the sschroevers/enable-BugPatternNaming-check branch from ff6c7e3 to 2886734 Compare August 7, 2022 15:50
@Stephan202
Copy link
Member Author

Rebased and added a tiny tweak. Will merge once built.

@Stephan202 Stephan202 merged commit 21646ff into master Aug 7, 2022
@Stephan202 Stephan202 deleted the sschroevers/enable-BugPatternNaming-check branch August 7, 2022 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants