Additional linting rules for Rust projects.
See the homepage or the rules/ directory for all the rules implemented so far.
See planned-rules/ for all the rules not yet implemented.
Install Dylint, then add perfectionist to your workspace's dylint.toml:
[workspace.metadata.dylint]
libraries = [
{ git = "https://github.com/KSXGitHub/perfectionist" },
]Run the lints:
cargo dylint --all -- --all-targetsEach lint registers under the perfectionist tool namespace. See CONTROLLING_RULES.md for how to change a rule's level per call site or project-wide, and how to enable or disable rules globally.
dylint.toml accepts a crate-wide [perfectionist] table and per-rule [perfectionist::<rule>] tables. See CONFIGURATION.md for the full schema.
Prerequisites:
cargo-dylint and dylint-link are not part of the cargo dependency graph but their ABI is coupled to it. They're installed into a workspace-local .dev-tools/ directory (pinned to the dylint_linting version in Cargo.lock) by:
just install-dev-toolsRun this once after cloning, and again whenever dylint_linting is bumped. Every other just recipe prepends .dev-tools/bin to PATH, so subsequent commands use the pinned binaries automatically.
Run the following command to check everything:
just allThis code base is almost entirely AI-generated. Or in other words, vibe-coded.
I needed a way to automatically force the AI agents I use to comply with a certain code style, reducing the time I'll have to spend micro-managing and reviewing AI-generated code. I cannot rely on them interpreting the rules in the Markdown guides correctly, and they often don't comply with the rules completely. Hence, I looked at the code style guides and thought: "Hmm, some of these rules can be coded into a program!" and so this program was born.
I needed encode these rules quick, so I chose vibe-coding.
The code quality of this code base is not as important as the code quality this code base will enforce upon others. This code base is, after all, scaffholding.