Code Style (WIP)
Code committed to the main branch is expected to be free of syntax errors, warnings, and fully linted - meaning all code flagged by a lint is either fixed to conform to said lint, or is appropriately annotated to allow the lint to fail on it. Code committed to an individual dev's working branch can be in any state (but must meet the above criteria before a PR is opened), while code in shared working branches should be error-free but may contain warnings.
When overriding a lint in code, the #[allow(..)] attribute MUST be
accompanied by a comment justifying why this lint is being permitted here; when
(if) the lint_reasons feature is stabilized, these should be converted to
#[expect(.., reason = "..")] attributes, where the reason will be required
in lieu of a comment to justify its presence.
Non-default lints are defined in the [lints.rust] and [lints.clippy] tables
in Cargo.toml. While conforming to the chosen lints will make the code
objectively better1, the choice of which lints to use is inherently a
subjective matter and is always open to discussion; feel free to bring it up
through your preferred medium, or simply open a PR with your proposed changes to
the lints tables to be discussed there.
Beyond whether or not it correctly performs its function and does so with acceptable performance, what code is "better" is inherently subjective - including (or especially) when any code is claimed to be "objectively" better than other code.