nexus/README.md

# 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.
Initial commit 2022-07-29 04:40:55 +00:00			`# nexus`

feat(README): added some code standards 2022-07-30 09:22:39 +00:00			`## 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.

feat(README): added plugin guidelines 2022-07-30 09:28:17 +00:00			`### 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.