-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add lint: Plugin not ending in "Plugin" #111
Conversation
You cannot implement `Plugin` for `*const T` since they are always foreign, and it's pretty-much pointless to implement `Plugin` for `&T` since `Plugin: 'static`.
Found two issues when running this on the engine itself:
|
After further thought, I think this is not something the lint should handle. Downstream it should be
This has been fixed in 20ac53a. |
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.
A small comment on the motivation part, but not a blocking one.
Overall, nicely documented!
//! Unlike traits like [`Clone`] or [`Debug`], the primary purpose of a type that implements | ||
//! `Plugin` is to be a Bevy plugin. As such, it is common practice to suffix plugin names with | ||
//! "Plugin" to signal how they should be used. |
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 believe we could expand on the motivation a bit. Currently it explains that this is a common practice, but not really why this is the case (or rather, why it is a good idea to follow it).
Digging into this a bit more will also help to resolve the question whether a Plugins
suffix should be allowed or not.
If the goal is to clearly distinguish a plugin struct from other structs to ensure that it is used in the correct places, then Plugins
would probably also accomplish that goal.
If it's more about strict consistency, then perhaps Plguins
should not be allowed.
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've personally always used the "Plugin" suffix for consistency with the ecosystem, but I've always favored consistency in my code.
@alice-i-cecile or @janhohenheim, would you like to pitch in here? Why should we encourage users to use the "Plugin" suffix for all Plugin
s?
Note to self: this should probably use |
I'm going to make this a follow-up issue. I'd rather get this merged as-is. |
This makes it more clear that the `impl` item is linted, not the original structure definition.
I did some more experimentation on this. It is far easier to lint on the While |
@BD103 feel free to merge this when you're ready, this LGTM. |
I'm going to merge this as-is. There is still the open question (#111 (comment)) on why we use the |
Closes #55.
This adds a lint that verifies that all plugins have the "Plugin" suffix, as that pattern is pretty-much standardized across the ecosystem. This is our first "Style" lint, meaning it tries to suggest idiomatic code.
Testing
Paste the following into
bevy_lint/examples/lint_test.rs
, runcd bevy_lint
, then runcargo build && cargo run -- --example lint_test
: