Mirrors/bevy
2
0
Fork 0
mirror of https://github.com/bevyengine/bevy synced 2024-11-25 22:20:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
bevy/.github/contributing/engine_style_guide.md
Alice Cecile d59fc076e8 Comprehensive CONTRIBUTING.md (#2040) 
[**RENDERED**](https://github.com/alice-i-cecile/bevy/blob/better-contributing/CONTRIBUTING.md)

Improves #910. As discussed in #1309, we'll need to synchronize content between this and the Bevy website in some way (and clean up the .github file perhaps?).

I think doing it as a root-directory file is nicer for discovery, but that's a conversation I'm interested in having.

This document is intended to be helpful to beginners to open source and Bevy, and captures what I've learned about our informal practices and values.

Reviewers: I'm particularly interested in:
- opinions on the items **What we're trying to build**, where I discuss some of the project's high-level values and goals
- more relevant details on the `bevy` subcrates for **Getting oriented**
- useful tricks and best practices that I missed
- better guidance on how to contribute to the Bevy book from @cart <3
2021-08-14 19:21:36 +00:00

858 B
Raw Blame History

Style guide: Engine

For more advice on contributing to the engine, see the relevant section of CONTRIBUTING.md.

  1. Prefer granular imports over glob imports of bevy::prelude::* and bevy::sub_crate::*.
  2. Use a consistent comment style:
    1. /// doc comments belong above #[derive(Trait)] invocations.
    2. // comments should generally go above the line in question, rather than in-line.
    3. Avoid /* */ block comments, even when writing long comments.
    4. Use `variable_name` code blocks in comments to signify that you're referring to specific types and variables.
    5. Start comments with capital letters. End them with a period if they are sentence-like.
  3. Use comments to organize long and complex stretches of code that can't sensibly be refactored into separate functions.