Use slimmer plugin syntax

[janhohenheim]

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

[tbillington]

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?

[janhohenheim]

Glad you like it! pub(super) is only visible to the mod above you, which is the only place that should be able to see your mini-plugin. If your mod is private, it makes no difference, but if you need to make it pub(crate) to export some Components, this means the following.

• You cannot accidentally import wrong plugins
• You don't get a giant list of plugin when you use autocomplete
• clippy gets to be a bit more accurate in telling you what is dead code.

[tbillington]

I've slowly moved away from super terse function names even if they don't get exported from a module. Seeing setup or update in a trace with no other info can be pretty annoying. The tools let you hover over to see which file it came from but it's still nicer at a glance to see a slightly more descriptive name.

Seeing all these fns just called plugin gives me the same ick. Though I guess they'll never really be relevant in a profile since they're startup only...

[janhohenheim]

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 foo_plugin, bar_plugin, etc. but have found it to be counterproductive.
There are three reasons I switched. First, each of my plugins is sitting in its own module, so the calls to add them look like this:

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 mod name.

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 plugin with the following:

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.

[tbillington]

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