Catalogue of perfectionist's lints — a Dylint plugin adding stylistic and correctness lints for Rust projects.
Developer toolsRust · JavaScriptGitHub @KSXGitHubOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Verify in one minuteAsk about other verification options
Additional linting rules for Rust projects
Translation pending
Taken from the repository README
Loading the full README. The saved excerpt is shown below.
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:
Each 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:: "] tables. See CONFIGURATION.md for the full schema.Read the full README ↗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-targets
Each 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-tools
Run 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 all
This 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.