# CONTRIBUTING

simple guidelines.

* Follow the coding guidelines when proposing code changes ([see below](#code-style)).

[guide]: https://radicle.xyz/guides/user#working-with-patches

[zulip]: https://radicle.zulipchat.com

Patch formatting follows the same rules as commit formatting. See below.

Always check your code with the linter (`clippy`), by running:

Finally, ensure there is no trailing whitespace anywhere.

Make sure all tests are passing with:

Some tests require `jq`. If `jq` is not detected, these tests will succeed

without effectively testing anything.

If you make documentation changes, you may want to check whether there are any

warnings or errors:

    $ cargo doc --workspace --all-features

The following code guidelines will help make code review smoother.

Use `unwrap` only in either of three circumstances:

    logger::init(log::Level::Debug)

        .expect("logger must only be initialized once");

Modules are declared at the top of the file, before the imports. Public modules

are separated from private modules with a blank line:

    use crate::storage::refs::Refs;

    use crate::storage::RemoteId;

Use short 1-letter names when the variable scope is only a few lines, or the context is

obvious, eg.

    pub const KEEP_ALIVE_DELTA: LocalDuration = LocalDuration::from_secs(30);

Stay concise. Use the function doc comment to describe

what the function does, not the name. Keep in mind functions are in the

context of the parent module and/or object and repeating that would be

redundant.

When writing log statements, always include a `target` and include enough

context in the log message that it is useful on its own, eg.

Check the file you are working on for what the `target` name should be; most

logs should be at the *debug* level.

Before adding any code dependencies, check with the maintainers if this is okay.

In general, we try not to add external dependencies unless it's necessary.

Dependencies increase counter-party risk, build-time, attack surface, and

make code harder to audit.

Public types and functions should be documented. Modules *may* be documented,

if you see the need.

    for rid in self.storage.inventory()? {

        ...

When proposing changes via a patch:

To help with the above, use `git commit --amend` and `git rebase -i`. You can

also interactively construct a commit from a working tree using `git add -p`.

A properly formed git commit subject line should always be able to complete the

following sentence: