nexus

Coding Standards

These are a set of standards for the nexus code-base to keep things clean, consistent, and understandable.

All code merged or pushed to main should follow these standards

Events and Resources

All structs that are used as event or resource in bevy should follow these rules

First, there should be no indication in the identifier that the object is an event. So Kill is valid, but KillEvent is not valid, and neither is EKill. There also should be no indication if struct is a resource so ColorResource or RColor are not allowed, but just Color is.

Second, all structs that are passed as events should not be naked if they contain data. So if a struct struct ConnectionHandler you cannot pass ConnectionHandler as an event, you must wrap it with a more descriptive name. This normally would result in redundant names, however with rust structs if you are wrapping data there will be a more descriptive name to use, for example ServerConnectionHandler(ConnectionHandler). We may want to use the ConnectionHandler resource or event more then once in our code, and wrapping it prevents conflicts, while also naming it more descriptively.

Third, you must put events and resources within their own local files event and resource and you should also only refer to them using the event::EVENT or resource::RESOURCE syntax. You should not import the full namespace down to event or resource, at maximum you can only import to the level before that. This helps to keep events and resources and other structs distinct.

Plugins

The plugin is a very important concept in bevy for modularity, and reusability. As such many pieces of nexus are split into multiple plugins. As plugins are once again structs given extra behavior they follow the rules above, placed in their own local plugin folder, however plugins are likely to be used outside of nexus so having plugin as part of the name, such as struct PayloadPlugin is not only permissible, but required, Plugin must be postfixed to the end of any plugin struct.