-
-
Notifications
You must be signed in to change notification settings - Fork 2
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
Use slimmer plugin syntax #3
Conversation
I've started using this style for https://github.com/janhohenheim/foxtrot and also introduced it to https://github.com/kaosat-dev/Blender_bevy_components_workflow. IMO it makes it much cleaner and easier to split your stuff into sub-plugins :)
Ah, I didn't realise you could make function plugins, nice! What's the rationale behind pub(super) vs pub(crate), I haven't seen it before. I guess it means you don't see "nested" plugins from higher levels than you'd expect to use them from? |
Glad you like it!
|
I've slowly moved away from super terse function names even if they don't get exported from a module. Seeing Seeing all these fns just called |
Very happy to bikeshed this, as these kinds of guidelines are still very much in progress in the Bevy ecosystem :) I fully agree in general and used to call my plugins mod foo;
mod bar;
mod baz;
app.add_plugins((
foo::plugin,
bar::plugin,
baz::plugin,
)); vs mod foo;
mod bar;
mod baz;
app.add_plugins((
foo::foo_plugin,
bar::bar_plugin,
baz::baz_plugin,
)); As you can see, the more terse version results in less noise due to the reduced repetition. There is also no mouseover tooling needed to find out what kind of plugin it is since its already encoded in the This leads to the second reason: I can easily rename my plugins by renaming only the mod without needing to touch the plugin function as well. The third reason is saved effort. Since I'm splitting my game into a ton of sub-plugins for organization, I'm creating new plugins all the time in their own module. A quick CTRL+F tells me I currently have 91 plugin functions in my project. Because adding a plugin is such an extremely common operation, it needs to be as low-friction as possible. In fact, I've setup an IDE shortcut that replaces use bevy::prelude::*;
pub(super) fn plugin(app: &mut App) {
todo!()
} If the terse name resulted in worse debugging or logging experience, I would probably switch back since I also try to be explicit in all my naming conventions, but as you said, this is not a problem for plugins. |
I have similar vscode snippets, seems we're pretty on the same page with a lot of things :D That makes a lot of sense, I like the change :) |
I've started using this style for https://github.com/janhohenheim/foxtrot and also introduced it to https://github.com/kaosat-dev/Blender_bevy_components_workflow. IMO it makes it much cleaner and easier to split your stuff into sub-plugins :)