Your Clippy Config Should Be Stricter-er

Today, I read this article: Your Clippy Config Should Be Stricter ↗. I agree with its basic premise — that is, your Clippy configuration should be stricter than the default — but I have a couple of disagreements about how we should go about doing this. So, I’m writing my recommended approach here.

Firstly, lint categories should be turned on, and then individual lints turned off according to your purposes. This means turning on the subjective pedantic and restriction categories. Doing this with the latter is explicitly dissuaded in Clippy’s documentation, and this is quoted in the aforementioned article. I think this is incorrect:

• Treating your lints like an allowlist means that it’s impossible to overlook a useful lint.
• If a lint implementation is buggy, that should be clear if you understand what it’s supposed to be warning against.
• The fact that some lints are contradictory is not reason enough to avoid turning the category on. Just make a decision about which (if any) makes sense depending on the situation.

Secondly, the author asserts that introducing a stricter configuration into an existing codebase is less tedious because coding agents can do it:

“Also, enabling new lints on an existing codebase is tedious, and exactly the kind of task that is good to hand to a coding agent.”

Actually, the friction is good and should not be avoided; having to confront every lint forces you to be intentional about what good, correct code looks like in the context of your project. Do not avoid thinking about these things.

So here’s what I think you should do.

1. Turn on pedantic and restriction in your Cargo.toml:

  [lints.clippy]
  pedantic = { level = "warn", priority = -1 }
  restriction = { level = "warn", priority = -2 }
  # save this one for personal projects maybe :)
  # nursery = { level = "warn", priority = -3 }

2. Go through every Clippy warning and decide whether that rule should: be allowed on a case-by-case basis (use #[expect(lint_name)]); always be allowed; or continue to warn.

3. Repeat step 2 as you write more code. You may encounter new lints, or you may be prompted to rethink a past decision on a familiar lint.

Generally speaking, prefer allowlists over denylists. As another example, you can apply a similar approach to your gitignore rules ↗.