Go to file
malek 93d25e93ba feat(README): added some code standards 2022-07-30 02:22:39 -07:00
bevy-add-events-macro feat(add_events): added add_events macro, and some small networking events partially. 2022-07-29 21:27:04 -07:00
client feat(add_events): added add_events macro, and some small networking events partially. 2022-07-29 21:27:04 -07:00
server feat(setup): basic workspace setup for development, and dependencies 2022-07-29 18:39:33 -07:00
src feat(add_events): added add_events macro, and some small networking events partially. 2022-07-29 21:27:04 -07:00
.gitignore Initial commit 2022-07-29 04:40:55 +00:00
Cargo.toml feat(setup): basic workspace setup for development, and dependencies 2022-07-29 18:39:33 -07:00
LICENSE Initial commit 2022-07-29 04:40:55 +00:00
README.md feat(README): added some code standards 2022-07-30 02:22:39 -07:00

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.