Skip to content
This repository was archived by the owner on May 3, 2022. It is now read-only.

Coding Style

Mark Bestavros edited this page Sep 23, 2019 · 4 revisions

Coding style for the Enarx project

The Enarx project follows the Rust coding guidelines.

Any further recommendation we issue should be due to the fact the Rust project has no official guideline on a specific aspect.

If you find one of our coding recommendations to be in contradiction with the Rust coding guidelines, the latter should prevail.

In any case, we will align to new Rust guidelines when published.

Versioning

Enarx uses semantic versioning.

Comments

Comments should be complete sentences with proper grammar.

They should describe both what the code is doing and why it is doing it.

Variable names

The Enarx project prefers the use of descriptive variable names that give an idea of what that variable is being used for. We do not enforce specific guidelines beyond this preference. For example, we will frown upon extremely short C-style names (think b with regards to a boolean variable).

Formatting

In keeping with our general policy on Rust guidelines outlined above, we expect all code submitted to the repository to conform to the Rust formatting guidelines. All Enarx repositories enforce this requirement as a gating test for new pull requests.

Fortunately, this is an easy requirement to satisfy using Rustfmt, Rust's official formatting tool. If not already installed, you can add it using rustup component add rustfmt. You can run it on any crate by running cargo fmt in a crate's root (the same directory that contains Cargo.toml).

Commit etiquette

Pull requests to Enarx repositories should contain logical commits. In other words, commits should only contain changes relevant to one feature or component of the code. This helps repositories maintain a coherent and understandable history of code changes.

To that end, merge commits are strictly not allowed. It is expected that any code up for a pull request will be rebased on top of the upstream Enarx repository's master branch. Fast-forward-only merges are acceptable if needed.

This quick video outlines the two predominant Git merging strategies. We follow fast-forward merging (the one on the left).

Where to next?

For more about contributing in general, please read our guide on how to contribute.

Clone this wiki locally