Linting with Clippy

20 min read

If ESLint is the tool that catches your bugs and bad habits in JavaScript and TypeScript, Clippy is its Rust counterpart. It ships with the toolchain, knows hundreds of idiomatic-Rust rules out of the box, and uses the exact same lint-level vocabulary (allow / warn / deny) you already know from ESLint and the compiler.

Quick Overview

Clippy is Rust’s official linter. It runs the same front-end as the compiler but adds 750+ extra lints that catch correctness bugs, performance traps, and non-idiomatic code. Unlike ESLint — which you install, configure, and wire into your build — Clippy comes with rustup, needs zero config to be useful, and its suggestions are frequently auto-applicable. For a TypeScript developer, the mental model is “ESLint, but built in, type-aware by default, and with a much higher signal-to-noise ratio.”

Note: The current stable toolchain is Rust 1.96.0 on the latest stable edition (2024). Clippy is versioned in lockstep with the compiler, so rustc 1.96.0 ships clippy 0.1.96. cargo new selects the newest edition automatically.

TypeScript/JavaScript Example

In the Node ecosystem, linting is a separate tool you opt into. A typical setup installs ESLint, writes a flat config (eslint.config.js), assigns each rule a level, and runs it through an npm script:

1
// eslint.config.js  (ESLint 9 flat config)
2
module.exports = [
3
  {
4
    rules: {
5
      "no-var": "error", // hard failure
6
      eqeqeq: "warn", // advisory
7
      "no-unused-vars": "off", // disabled
8
    },
9
  },
10
];

1
var x = 1;
2
if (x == "1") {
3
  console.log("loose equality");
4
}

Running npx eslint demo.js produces:

1
/private/tmp/eslint_probe/demo.js
2
  1:1  error    Unexpected var, use let or const instead  no-var
3
  2:7  warning  Expected '===' and instead saw '=='       eqeqeq
4

5
2 problems (1 error, 1 warning)
6
  1 error and 0 warnings potentially fixable with the `--fix` option.

Note the three rule levels ("error", "warn", "off"), the --fix flag for auto-fixable rules, and the fact that none of this works until you install ESLint and write a config. Those three concepts map almost one-to-one onto Clippy.

Rust Equivalent

Clippy needs no installation in a standard rustup setup and no config file to start producing value. Write some non-idiomatic Rust:

1
fn main() {
2
    let numbers = vec![1, 2, 3];
3
    if numbers.len() == 0 {
4
        println!("empty");
5
    }
6

7
    let opt: Option<i32> = Some(5);
8
    if opt.is_some() {
9
        let value = opt.unwrap();
10
        println!("{value}");
11
    }
12
}

Then run cargo clippy:

1
warning: length comparison to zero
2
 --> src/main.rs:3:8
3
  |
4
3 |     if numbers.len() == 0 {
5
  |        ^^^^^^^^^^^^^^^^^^ help: using `is_empty` is clearer and more explicit: `numbers.is_empty()`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#len_zero
8
  = note: `#[warn(clippy::len_zero)]` on by default
9

10
warning: called `unwrap` on `opt` after checking its variant with `is_some`
11
  --> src/main.rs:8:21
12
   |
13
7  |     if opt.is_some() {
14
   |     ---------------- help: try: `if let Some(<item>) = opt`
15
8  |         let value = opt.unwrap();
16
   |                     ^^^^^^^^^^^^
17
   |
18
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_unwrap
19
   = note: `#[warn(clippy::unnecessary_unwrap)]` on by default
20

21
warning: useless use of `vec!`
22
 --> src/main.rs:2:19
23
  |
24
2 |     let numbers = vec![1, 2, 3];
25
  |                   ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`
26
  |
27
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_vec
28
  = note: `#[warn(clippy::useless_vec)]` on by default

Three lints fired, each pointing at the exact span, naming the rule (clippy::len_zero, clippy::unnecessary_unwrap, clippy::useless_vec), suggesting the fix, and linking to its documentation — all with zero configuration.

Tip: Every Clippy lint is documented and searchable in The Clippy Lints index. The #name fragment in each help: URL jumps straight to that lint.

Detailed Explanation

Installing and running

If you installed Rust via rustup (the recommended path), Clippy is already there as the clippy component. If it is somehow missing:

1
rustup component add clippy

You run it through Cargo, exactly like cargo build or cargo test:

1
cargo clippy

Under the hood, cargo clippy invokes a special Clippy driver in place of rustc. Because it reuses the compiler’s own analysis — full type information, borrow checking, the works — Clippy is type-aware by default. ESLint only becomes type-aware when you add the typescript-eslint typed-linting rules and point it at your tsconfig.json; Clippy gets that for free because it is the compiler front-end.

A subtle but important consequence: cargo build and cargo check do not run Clippy lints. The clean-build output for the same code above is just:

1
   Compiling clippy_probe v0.1.0 (/path/to/clippy_probe)
2
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.11s

No lint warnings at all. Clippy is a separate pass you (or your CI) must invoke explicitly. This is different from ESLint, which most teams wire into a pre-commit hook or npm run build, but it parallels how you have to run eslint itself — tsc alone never runs ESLint rules either.

The three lint levels

Every Rust lint — both the compiler’s own and Clippy’s — sits at one of four levels. Three of them line up directly with ESLint:

ESLint level	Rust/Clippy level	Effect
`"off"`	`allow`	Lint is silenced; no diagnostic.
`"warn"`	`warn`	Prints a warning; compilation still succeeds.
`"error"`	`deny`	Prints an error; compilation fails (non-zero exit code).
(none)	`forbid`	Like `deny`, but can no longer be overridden by an `allow`.

forbid has no ESLint analogue — it is deny that downstream code is forbidden from re-allowing. Use it sparingly for lints you consider non-negotiable.

Where Clippy lints come from: lint groups

ESLint rules are individually named (no-var, eqeqeq). Clippy lints are individually named too (clippy::len_zero), but they are also organized into groups you can target wholesale — much like an ESLint config preset such as eslint:recommended:

Clippy group	Default level	What it contains
`clippy::all`	`warn`	The sensible default set: `correctness`, `suspicious`, `style`, `complexity`, `perf`. This is what runs out of the box.
`clippy::correctness`	`deny`	Almost-certainly-wrong code. On by default and already denied.
`clippy::pedantic`	`allow`	Stricter, sometimes opinionated lints. Off by default; opt in.
`clippy::nursery`	`allow`	New lints still being refined. May have false positives.
`clippy::cargo`	`allow`	Lints about your `Cargo.toml` metadata.
`clippy::restriction`	`allow`	A grab-bag of lints that are not recommended wholesale — enable individual ones only.

The key insight: clippy::all is the curated, high-signal default. clippy::pedantic is the “I want the strict opinions too” preset, comparable to enabling a strict ESLint shared config like airbnb. You opt into it explicitly:

1
cargo clippy -- -W clippy::pedantic

Anything after -- is passed to the Clippy/rustc driver. With pedantic on, the same code can surface extra advice:

1
warning: this argument is passed by value, but not consumed in the function body
2
 --> src/main.rs:1:18
3
  |
4
1 | fn process(data: String) -> usize {
5
  |                  ^^^^^^ help: consider changing the type to: `&str`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_pass_by_value
8
  = note: `-W clippy::needless-pass-by-value` implied by `-W clippy::pedantic`

Warning: Do not blanket-deny clippy::pedantic, clippy::nursery, or clippy::restriction in a real project. They contain opinionated and occasionally noisy lints; a hard deny on them turns every Clippy upgrade into a potential build breakage. Set them to warn if you want the advice, and deny only the curated clippy::all.

Controlling levels: three layers

You can set lint levels in three places, in increasing order of precedence (the innermost wins):

Cargo.toml [lints] table — project-wide, version-controlled, the modern default.
Command-line / crate-root attributes — e.g. -W clippy::pedantic or #![deny(clippy::all)].
Item-level attributes — e.g. #[allow(clippy::useless_vec)] on a single statement, like an ESLint // eslint-disable-next-line comment.

The next two sections cover each. They are exactly the ESLint pattern of “config file → CLI flag → inline disable comment,” just expressed in Rust syntax.

Key Differences

`#![deny(clippy::all)]` — promoting warnings to hard errors

By default Clippy warns. To make lints fail the build — the Rust equivalent of an ESLint rule set to "error" — promote them to deny. The most common gate is a crate-root inner attribute:

1
#![deny(clippy::all)]
2

3
fn main() {
4
    let numbers = vec![1, 2, 3];
5
    if numbers.len() == 0 {
6
        println!("empty");
7
    }
8
}

Now cargo clippy reports errors, not warnings, and exits non-zero:

1
error: length comparison to zero
2
 --> src/main.rs:5:8
3
  |
4
5 |     if numbers.len() == 0 {
5
  |        ^^^^^^^^^^^^^^^^^^ help: using `is_empty` is clearer and more explicit: `numbers.is_empty()`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#len_zero
8
note: the lint level is defined here
9
 --> src/main.rs:1:9
10
  |
11
1 | #![deny(clippy::all)]
12
  |         ^^^^^^^^^^^
13
  = note: `#[deny(clippy::len_zero)]` implied by `#[deny(clippy::all)]`
14

15
error: useless use of `vec!`
16
 --> src/main.rs:4:19
17
  |
18
4 |     let numbers = vec![1, 2, 3];
19
  |                   ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`
20
  |
21
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_vec
22
  = note: `#[deny(clippy::useless_vec)]` implied by `#[deny(clippy::all)]`
23

24
error: could not compile `clippy_probe` (bin "clippy_probe") due to 2 previous errors

The process exits with code 101. That non-zero exit is what makes Clippy a real gate in CI: the job fails, the PR is blocked.

Note: The #![...] form (with the bang) is an inner attribute — it applies to the whole crate from the crate root (main.rs or lib.rs). The #[...] form (no bang) is an outer attribute that applies to the next item. Both are real Rust attributes and render correctly in plain markdown; they are unrelated to the rustdoc hidden-line # syntax.

`-D warnings` — the CI one-liner

The crate attribute lives in source. For CI, the common pattern is to leave the code clean and flip every warning to deny from the command line:

1
cargo clippy -- -D warnings

-D is the short form of deny, and warnings is a special lint group meaning “all warnings.” This is the single most common Clippy invocation in CI pipelines: any lint at warn becomes a build-breaking error.

1
error: useless use of `vec!`
2
 --> src/main.rs:2:19
3
  |
4
2 |     let numbers = vec![1, 2, 3];
5
  |                   ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_vec
8
  = note: `-D clippy::useless-vec` implied by `-D warnings`
9
  = help: to override `-D warnings` add `#[allow(clippy::useless_vec)]`
10

11
error: could not compile `clippy_probe` (bin "clippy_probe") due to 1 previous error

The difference from #![deny(clippy::all)]: -D warnings denies everything that is currently a warning (including plain rustc warnings and any pedantic lints you enabled), while #![deny(clippy::all)] denies only the curated Clippy group. Most teams use both — a [lints] table for the project’s baseline and -D warnings in CI as a belt-and-suspenders gate.

The modern config home: the `[lints]` table

The current-stable way to configure lints project-wide is the [lints] table in Cargo.toml (stable since Cargo 1.74). This is the closest thing to an eslint.config.js: version-controlled, applies to every cargo clippy invocation, and works across a workspace.

1
[package]
2
name = "clippy_probe"
3
version = "0.1.0"
4
edition = "2024"
5

6
[lints.clippy]
7
all = { level = "deny", priority = -1 }
8
unwrap_used = "warn"

1
fn main() {
2
    let numbers = vec![1, 2, 3];
3
    println!("{}", numbers.len());
4
}

A plain cargo clippy now fails because the table denied clippy::all:

1
error: useless use of `vec!`
2
 --> src/main.rs:2:19
3
  |
4
2 |     let numbers = vec![1, 2, 3];
5
  |                   ^^^^^^^^^^^^^ help: you can use an array directly: `[1, 2, 3]`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_vec
8
  = note: `-D clippy::useless-vec` implied by `-D clippy::all`
9
  = help: to override `-D clippy::all` add `#[allow(clippy::useless_vec)]`
10

11
error: could not compile `clippy_probe` (bin "clippy_probe") due to 1 previous error

Tip: The priority = -1 on a group is essential. Cargo applies lints in priority order (lower numbers first), so a group at priority = -1 is applied before individual lints at the default priority = 0. That lets a specific lint override the group — e.g. all denied at -1, then a single lint relaxed to warn at 0. Forget the negative priority and Cargo will reject the manifest with an ambiguous-ordering error.

For a multi-crate workspace, declare the lints once at the workspace root and inherit them per-crate — see Cargo Deep Dive for the [workspace.lints] + [lints] workspace = true pattern.

Common Pitfalls

Pitfall 1: Expecting `cargo build` to run Clippy

A TypeScript developer used to ESLint running inside npm run build may assume cargo build lints. It does not. cargo build and cargo check only run the compiler’s own (much smaller) lint set. Clippy’s extra lints appear only when you run cargo clippy. Always add a dedicated cargo clippy step to your scripts and CI.

Pitfall 2: Suppressing a lint by deleting it instead of `allow`-ing it

Sometimes a lint is wrong for your situation. The fix is not to disable Clippy globally — it is to allow that one lint at the narrowest scope, the way you would write // eslint-disable-next-line:

1
fn main() {
2
    #[allow(clippy::useless_vec)]
3
    let numbers = vec![1, 2, 3];
4
    println!("{}", numbers.len());
5
}

That produces a clean run (exit 0), and the suppression is documented in place. Prefer item-level #[allow] over crate-level #![allow] — the broad version silences the lint everywhere and hides future real hits.

Pitfall 3: `unwrap` survives Clippy by default

New Rustaceans often expect Clippy to flag every .unwrap(). It does not by default — .unwrap() is fine in tests, prototypes, and provably-safe spots. The clippy::unwrap_used lint that bans it lives in the restriction group and is allow by default. If your team wants to forbid unwrap in production code, opt in explicitly (e.g. unwrap_used = "warn" in the [lints] table, as shown earlier). Clippy will warn when an .unwrap() is provably pointless (e.g. right after an is_some() check, via clippy::unnecessary_unwrap), but it will not police all of them. See Error Handling for when unwrap is appropriate.

Pitfall 4: Blanket-denying `pedantic` and getting surprised by upgrades

#![deny(clippy::pedantic)] feels rigorous, but pedantic is opinionated and grows with every release. A toolchain bump can introduce a new pedantic lint that suddenly fails your build on code that did not change. Keep pedantic/nursery at warn, and reserve deny for clippy::all (or specific lints you have deliberately chosen).

Pitfall 5: Forgetting `--all-targets` / `--all-features`

cargo clippy by default lints the default target set and default features only. Code behind #[cfg(test)], in benches, in examples, or behind non-default feature flags goes unlinted. For a thorough check (and the standard CI invocation), use:

1
cargo clippy --all-targets --all-features -- -D warnings

Best Practices

Run cargo clippy locally before every push, and gate it in CI with cargo clippy --all-targets --all-features -- -D warnings. A green Clippy run should be a merge requirement, just like a passing test suite.
Put the project baseline in the [lints] table of Cargo.toml (or [workspace.lints] for a workspace) so the policy is version-controlled and applies to every contributor and editor — rust-analyzer reads it and surfaces the same diagnostics inline.

Deny the curated group, warn the opinionated ones:

1
[lints.clippy]
2
all = { level = "deny", priority = -1 }
3
pedantic = { level = "warn", priority = -1 }

Use cargo clippy --fix for the mechanical ones. Many lints are auto-applicable. Given this code:

1
fn main() {
2
    let numbers = vec![1, 2, 3];
3
    if numbers.len() == 0 {
4
        println!("empty");
5
    } else {
6
        println!("{} items", numbers.len());
7
    }
8
}

Running cargo clippy --fix (add --allow-no-vcs outside a git repo) rewrites it in place to the idiomatic form:

1
fn main() {
2
    let numbers = [1, 2, 3];
3
    if numbers.is_empty() {
4
        println!("empty");
5
    } else {
6
        println!("{} items", numbers.len());
7
    }
8
}

This is Clippy’s --fix, the direct analogue of eslint --fix. It only applies suggestions Clippy marks as machine-applicable, so it is safe to run and review as a diff.

Prefer #[expect(...)] over #[allow(...)] for intentional suppressions (stable since Rust 1.81). expect behaves like allow, but if the lint stops firing, Clippy warns that the expectation is now unfulfilled — so a suppression you no longer need does not silently rot:

1
fn main() {
2
    // If the `vec!` were later changed to an array, `useless_vec` would no
3
    // longer fire, and Clippy would flag this attribute as unnecessary.
4
    #[expect(clippy::useless_vec)]
5
    let numbers = vec![1, 2, 3];
6
    println!("{}", numbers.len());
7
}

When the lint is no longer triggered, you get a helpful nudge instead of dead config:

1
warning: this lint expectation is unfulfilled
2
 --> src/main.rs:4:14
3
  |
4
4 |     #[expect(clippy::useless_vec)]
5
  |              ^^^^^^^^^^^^^^^^^^^
6
  |
7
  = note: `#[warn(unfulfilled_lint_expectations)]` on by default

Document why a lint is suppressed with the reason field (stable since 1.81), the equivalent of a comment after an ESLint disable directive:
```
1
#[allow(clippy::useless_vec, reason = "grows at runtime")]
2
let mut numbers = vec![1, 2, 3];
```

Real-World Example

A production crate typically sets a strict-but-sane lint policy in Cargo.toml, then keeps the code clean enough to pass it. Here is a small order-total module configured to deny clippy::all and warn on pedantic — and written to satisfy both.

1
[package]
2
name = "clippy_probe"
3
version = "0.1.0"
4
edition = "2024"
5

6
[lints.clippy]
7
all = { level = "deny", priority = -1 }
8
pedantic = { level = "warn", priority = -1 }
9

10
[dependencies]

1
//! A small order-total calculator that passes a strict Clippy config.
2

3
/// A line item in a shopping cart.
4
#[derive(Debug, Clone)]
5
pub struct LineItem {
6
    pub name: String,
7
    pub unit_price_cents: u32,
8
    pub quantity: u32,
9
}
10

11
/// Returns the total price in cents, applying a percentage discount.
12
///
13
/// # Panics
14
/// Never panics: arithmetic uses `u64` accumulators to avoid overflow.
15
#[must_use]
16
pub fn cart_total_cents(items: &[LineItem], discount_percent: u8) -> u64 {
17
    let subtotal: u64 = items
18
        .iter()
19
        .map(|item| u64::from(item.unit_price_cents) * u64::from(item.quantity))
20
        .sum();
21

22
    let discount = subtotal * u64::from(discount_percent) / 100;
23
    subtotal - discount
24
}
25

26
fn main() {
27
    let cart = [
28
        LineItem { name: "Keyboard".to_string(), unit_price_cents: 4_999, quantity: 1 },
29
        LineItem { name: "Mouse".to_string(), unit_price_cents: 2_500, quantity: 2 },
30
    ];
31

32
    let total = cart_total_cents(&cart, 10);
33
    println!("Total: ${}.{:02}", total / 100, total % 100);
34
}

cargo clippy passes with no diagnostics, and the program runs:

1
    Checking clippy_probe v0.1.0 (/path/to/clippy_probe)
2
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s

1
Total: $90.00

Notice the idioms that keep pedantic quiet: #[must_use] on a pure function, u64::from(...) instead of an as cast (the pedantic cast_lossless lint prefers From), taking &[LineItem] rather than Vec<LineItem> by value, and a # Panics doc section. This is what “Clippy-clean production Rust” looks like — the linter nudges you toward these conventions, and once internalized they become automatic. For a guided tour of the specific lints and their before/after rewrites, see Common Clippy Lints.

Exercises

Exercise 1: Run and read Clippy

Difficulty: Beginner

Objective: Get comfortable invoking Clippy and interpreting its output.

Instructions: Create a new project with cargo new lint_practice. Paste the following into src/main.rs, run cargo clippy, and identify which lint name fires and what fix it suggests. Then apply the fix and confirm a clean run.

1
fn main() {
2
    let words = vec!["alpha", "beta", "gamma"];
3
    let count = words.iter().count();
4
    println!("{} words", count);
5
}

Solution

cargo clippy reports clippy::needless_collect-adjacent advice — specifically the clippy::iter_count lint, which notes that calling .iter().count() is needlessly indirect when .len() exists. The real output:

1
warning: called `.iter().count()` on a `Vec`
2
 --> src/main.rs:3:17
3
  |
4
3 |     let count = words.iter().count();
5
  |                 ^^^^^^^^^^^^^^^^^^^^ help: try: `words.len()`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#iter_count
8
  = note: `#[warn(clippy::iter_count)]` on by default

The fixed, Clippy-clean version:

1
fn main() {
2
    let words = ["alpha", "beta", "gamma"];
3
    let count = words.len();
4
    println!("{count} words");
5
}

(Clippy also flags the vec! as a useless_vec since the collection is never mutated — switching to an array [...] clears that too.)

Exercise 2: Gate the build with a lint policy

Difficulty: Intermediate

Objective: Configure a project so a specific anti-pattern fails the build, while documenting one intentional exception.

Instructions: In a Cargo.toml, add a [lints] table that denies clippy::all and warns on clippy::unwrap_used. Then write src/main.rs that contains one .unwrap() you genuinely intend to keep (e.g. in a clearly-safe constant context), suppressing just that one lint with #[expect(...)] and a reason. Confirm cargo clippy exits 0.

Solution

1
[package]
2
name = "lint_practice"
3
version = "0.1.0"
4
edition = "2024"
5

6
[lints.clippy]
7
all = { level = "deny", priority = -1 }
8
unwrap_used = "warn"
9

10
[dependencies]

1
fn main() {
2
    // A parse that cannot fail on a hard-coded literal. We expect the
3
    // `unwrap_used` warning here and document why it is acceptable.
4
    #[expect(clippy::unwrap_used, reason = "literal is a valid u32")]
5
    let port: u32 = "8080".parse().unwrap();
6

7
    println!("Listening on port {port}");
8
}

cargo clippy exits 0 with no diagnostics: clippy::all is satisfied (no useless vec!, idiomatic formatting), and the single unwrap_used warning is silenced by the #[expect], whose expectation is fulfilled because the lint does fire there. If you later remove the .unwrap(), Clippy will warn that the expectation is unfulfilled, prompting you to drop the now-stale attribute.

Exercise 3: Opt into pedantic and resolve a real finding

Difficulty: Advanced

Objective: Experience the stricter pedantic preset and refactor toward idiomatic Rust.

Instructions: Take the function below, run cargo clippy -- -W clippy::pedantic, and resolve the pedantic finding by changing the signature — without changing what the function does. (Hint: the lint is about taking ownership you do not need.)

1
fn shout(message: String) -> String {
2
    message.to_uppercase()
3
}
4

5
fn main() {
6
    let msg = String::from("ship it");
7
    println!("{}", shout(msg));
8
}

Solution

With pedantic enabled, Clippy fires clippy::needless_pass_by_value: shout takes a String by value but only reads it, so it forces every caller to give up ownership for no reason. The fix is to accept a borrow, &str, which also makes the function callable with &String, &str, and string literals alike:

1
fn shout(message: &str) -> String {
2
    message.to_uppercase()
3
}
4

5
fn main() {
6
    let msg = String::from("ship it");
7
    println!("{}", shout(&msg));
8
    // `msg` is still usable here because we only borrowed it.
9
    println!("original still owned: {msg}");
10
}

cargo clippy -- -W clippy::pedantic now reports no warnings. This &str-over-String parameter convention is one of the most common pieces of advice the pedantic group teaches; see Ownership for the deeper “borrow what you only read” principle behind it.

Linting with Clippy

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Installing and running

The three lint levels

Where Clippy lints come from: lint groups

Controlling levels: three layers

Key Differences

#![deny(clippy::all)] — promoting warnings to hard errors

-D warnings — the CI one-liner

The modern config home: the [lints] table

Common Pitfalls

Pitfall 1: Expecting cargo build to run Clippy

Pitfall 2: Suppressing a lint by deleting it instead of allow-ing it

Pitfall 3: unwrap survives Clippy by default

Pitfall 4: Blanket-denying pedantic and getting surprised by upgrades

Pitfall 5: Forgetting --all-targets / --all-features

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Run and read Clippy

Exercise 2: Gate the build with a lint policy

Exercise 3: Opt into pedantic and resolve a real finding

`#![deny(clippy::all)]` — promoting warnings to hard errors

`-D warnings` — the CI one-liner

The modern config home: the `[lints]` table

Pitfall 1: Expecting `cargo build` to run Clippy

Pitfall 2: Suppressing a lint by deleting it instead of `allow`-ing it

Pitfall 3: `unwrap` survives Clippy by default

Pitfall 4: Blanket-denying `pedantic` and getting surprised by upgrades

Pitfall 5: Forgetting `--all-targets` / `--all-features`