kata-containers/cloud-hypervisor
1
0
Fork 0
mirror of https://github.com/cloud-hypervisor/cloud-hypervisor.git synced 2026-08-05 02:19:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: refine coding standards in CONTRIBUTING.md

Browse Source 
TL;DR: Add note about how we expect code comments/documentation

This updates the coding standards as discussed [0]. The general
guideline is to write down as little process as possible and leave room
for pragmatic exceptions, maintainer and contributor preferences while
still striving for excellent code quality.

[0]: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/7990#issuecomment-4245571054

On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
This commit is contained in:
Philipp Schuster
2026-04-15 10:22:14 +02:00
committed by Rob Bradford
parent edfd597993
commit 39844e8839
1 changed files with 23 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
CONTRIBUTING.md
View File

@@ -11,11 +11,30 @@ license of those projects.
New code should be under the [Apache v2
License](https://opensource.org/licenses/Apache-2.0).
## Coding Style
## Coding Style & Code Comments
We follow the [Rust Style](https://github.com/rust-lang/rust/tree/HEAD/src/doc/style-guide/src)
convention and enforce it through the Continuous Integration (CI) process calling into `rustfmt`,
`clippy`, and other well-known code quality tool of the ecosystem for each submitted Pull Request (PR).
We use the [Rust Style] guide and enforce formatting and linting in CI,
including `rustfmt`, `clippy`, and other common Rust quality checks, for every
pull request. We adapt to best practices, new lints and new tooling as the
ecosystem evolves.
Code should **speak for itself** (for example, by using descriptive identifiers)
and be **easy to read and maintain**. Beyond the conventions and tooling
described above, contributors have _some_ room to apply their own style and
preferred structure. Maintainers may still suggest refactorings where they
believe readability, consistency, or maintainability can be improved.
For new code, add documentation and comments where they **provide additional value**:
* **Rustdoc** explains the API to its users.
* **Inline comments** explain the code the reader, especially *why* it is
written that way.
* **Commit messages** explain the broader context of a change (for more
information on commit messages, see below).
Comments should be concise and add additional context or information to the code.
[Rust Style]: https://github.com/rust-lang/rust/tree/HEAD/src/doc/style-guide/src
## Basic Checks