diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 7339ea93..bf8c71d0 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,20 +1,7 @@ - ## Description - ## Testing - -## Checklist -Things need to be done before this Pull Request can be merged. - -- [ ] Code is well-formatted and adheres to project style guidelines: `cargo fmt` -- [ ] Code does not produce any clippy warnings: `cargo clippy` -- [ ] All unit tests pass: `cargo test` -- [ ] I added new unit tests, so other people don't accidentally break my code by changing other parts of the codebase. [How?](https://doc.rust-lang.org/book/ch11-01-writing-tests.html) +Please follow our [Coding Guidelines](https://github.com/Pumpkin-MC/Pumpkin/blob/master/CONTRIBUTING.md#coding-guidelines) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 690cbb93..e04fe5ee 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -29,16 +29,27 @@ There are several ways you can contribute to Pumpkin: The Documentation of Pumpkin can be found at -**Tip: [typos](https://github.com/crate-ci/typos) is a great Project to detect and automatically fix typos +**Tip: [typos](https://github.com/crate-ci/typos) is a great Project to detect and automatically fix typos** ### Coding Guidelines +Things need to be done before this Pull Request can be merged. Your CI also checks most of them automaticly and fill fail if something is not fulfilled +Note: Pumpkin's clippy settings are relativly strict, this can be may frustrating but is necesarry so the code says clean and conssistent +**Basic** + +- **Code Formatting:** Code must be well-formatted and follow the project's style guidelines. You can achieve this by running `cargo fmt`. +- **No Clippy Warnings:** Code should not produce any warnings from the Clippy linter. You can check for warnings using `cargo clippy --all-targets`. +- **Passing Unit Tests:** All existing unit tests must pass successfully. You can run the tests with `cargo test`. + +**Best Pratice** + +- **Writing Unit Tests:** When adding new features or modifying existing code, consider adding unit tests to prevent regressions in the future. Refer to the Rust documentation for guidance on writing tests: https://doc.rust-lang.org/book/ch11-01-writing-tests.html +- **Benchmarking:** If your changes might impact performance, consider adding benchmarks to track performance regressions or improvements. We use the Criterion library for benchmarking. Refer to their Quick Start guide for more information: https://github.com/bheisler/criterion.rs#quickstart +- **Clear and Concise Commit Messages:** Use clear and concise commit messages that describe the changes you've made. +- **Code Style:** Adhere to consistent coding style throughout your contributions. +- **Documentation:** If your changes introduce new functionality, consider updating the relevant documentation. - **Working with Tokio and Rayon:** - When invoking CPU intensive work, this work should be done in the Rayon thread pool via `rayon::spawn`, Rayon's - parallel iterators, or otherwise instead of from the Tokio runtime. However, it is important that the - Tokio runtime not block on these Rayon calls. Instead, the data should be passed to the Tokio runtime - via async means, for example: `tokio::sync::mpsc`. An example of how to properly do this can be found - in `pumpkin_world::level::Level::fetch_chunks`. + When dealing with CPU-intensive tasks, it's recommended to utilize Rayon's thread pool (`rayon::spawn`), parallel iterators, or similar mechanisms instead of the Tokio runtime. However, it's crucial to avoid blocking the Tokio runtime on Rayon calls. Instead, use asynchronous methods like `tokio::sync::mpsc` to transfer data between the two runtimes. Refer to `pumpkin_world::level::Level::fetch_chunks` for an example of this approach. ### Additional Information