Common Clippy Lints, Explained

22 min read

Quick Overview

Clippy ships with over 750 lints, and the first time you run it on a real codebase it can feel like a very opinionated code reviewer dumped a wall of warnings on you. This page walks through the handful of lints you will actually see every day — needless_return, uninlined_format_args, clone_on_copy, len_zero, redundant_clone, and friends — with a before/after for each and the real Clippy output. The goal is that after reading this you can look at a warning, understand why Clippy is suggesting the change, and decide whether to take it.

Note: This file is the “lint catalogue”. For how to run Clippy, set lint levels (allow/warn/deny), and wire #![deny(clippy::all)] into a crate, see linting.md. For the formatter (rustfmt), see formatting.md.

TypeScript/JavaScript Example

A senior TypeScript developer is used to ESLint plus typescript-eslint rules like no-useless-return, prefer-template, @typescript-eslint/prefer-string-starts-ends-with, and no-unnecessary-condition. Those rules push you toward idiomatic, less-error-prone code, and you mostly internalize them until you stop writing the flagged patterns at all.

Here is a small order-summary helper that an ESLint config with the recommended rules would nudge on:

1
interface Order {
2
  id: number;
3
  items: string[];
4
  note?: string;
5
}
6

7
function summarize(order: Order): string {
8
  const id = order.id;
9
  const count = order.items.length;
10

11
  // ESLint: prefer `order.items.length === 0` is fine in JS, but the analogous
12
  // Rust `.len() == 0` has a dedicated `.is_empty()`.
13
  if (order.items.length === 0) {
14
    return "empty order";
15
  }
16

17
  // no-useless-return / prefer-template territory:
18
  const note = order.note ?? "(none)";
19
  const names = order.items.map((i) => i); // pointless .map identity
20
  return "order " + id + " has " + count + " items: " + names.join(", ") + " [" + note + "]";
21
}
22

23
console.log(summarize({ id: 7, items: ["pen", "ink"] }));

The ESLint analogues here would be prefer-template (use a template literal instead of + concatenation) and the pointless identity .map((i) => i). Clippy is the same kind of tool for Rust, except its suggestions are usually machine-applicable — it can rewrite the code for you.

Rust Equivalent

Here is the same function written the way a TypeScript developer often writes Rust on day one. It compiles and runs correctly, but Clippy has opinions about almost every line:

1
// src/main.rs — the "before". Compiles, runs, but Clippy flags it.
2
#[derive(Debug)]
3
struct Order {
4
    id: u32,
5
    items: Vec<String>,
6
    note: Option<String>,
7
}
8

9
fn summarize(order: &Order) -> String {
10
    let id = order.id;
11
    let count = order.items.len();
12
    if order.items.len() == 0 {
13
        return String::from("empty order");
14
    }
15
    let note = order.note.clone().unwrap_or(String::from("(none)"));
16
    let names: Vec<String> = order.items.iter().map(|i| i.clone()).collect();
17
    return format!("order {} has {} items: {} [{}]", id, count, names.join(", "), note);
18
}
19

20
fn main() {
21
    let order = Order {
22
        id: 7,
23
        items: vec![String::from("pen"), String::from("ink")],
24
        note: None,
25
    };
26
    println!("{}", summarize(&order));
27
}

Running cargo clippy on this (with #![warn(clippy::uninlined_format_args)] added so the format-string lint also fires) produces real warnings for len() == 0, the identity .map(|i| i.clone()), the trailing return, and the un-inlined format arguments. Here is the cleaned-up after — it is Clippy-clean even under the stricter clippy::pedantic group, and arguably easier to read:

1
// src/main.rs — the "after". Clean under `cargo clippy -- -W clippy::pedantic`.
2
#[derive(Debug)]
3
struct Order {
4
    id: u32,
5
    items: Vec<String>,
6
    note: Option<String>,
7
}
8

9
fn summarize(order: &Order) -> String {
10
    if order.items.is_empty() {
11
        return String::from("empty order");
12
    }
13
    let id = order.id;
14
    let count = order.items.len();
15
    let note = order.note.as_deref().unwrap_or("(none)");
16
    let names = order.items.join(", ");
17
    format!("order {id} has {count} items: {names} [{note}]")
18
}
19

20
fn main() {
21
    let order = Order {
22
        id: 7,
23
        items: vec![String::from("pen"), String::from("ink")],
24
        note: None,
25
    };
26
    println!("{}", summarize(&order));
27
}

Running it prints:

1
order 7 has 2 items: pen, ink [(none)]

The rest of this page breaks the individual lints out one at a time, because each one teaches a small, transferable piece of “how Rust wants to be written”.

Detailed Explanation

Each lint below shows the before, the real Clippy warning (captured by running cargo clippy on a probe project with rustc 1.96.0 / clippy 0.1.96), and the after. Every warning ends with a help: link to rust-lang.github.io/rust-clippy, and tells you the lint name in the #[warn(...)] note — that name is what you allow/deny (see linting.md).

`needless_return` — drop the trailing `return`

Rust is expression-oriented: the last expression in a block is the return value, no return keyword needed. Coming from JavaScript, where return is mandatory, you will reach for it reflexively.

1
// before
2
fn needless_return(x: i32) -> i32 {
3
    return x + 1;
4
}

Real Clippy output:

1
warning: unneeded `return` statement
2
 --> src/main.rs:7:5
3
  |
4
7 |     return x + 1;
5
  |     ^^^^^^^^^^^^
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_return
8
  = note: `#[warn(clippy::needless_return)]` on by default
9
help: remove `return`
10
  |
11
7 -     return x + 1;
12
7 +     x + 1
13
  |

1
// after
2
fn needless_return(x: i32) -> i32 {
3
    x + 1
4
}

Tip: Note the missing semicolon. x + 1 is an expression that becomes the function’s value; x + 1; is a statement of type () and would be a type error. An early return in the middle of a function (like the is_empty() guard above) is fine and idiomatic — needless_return only fires on a return in tail position.

`uninlined_format_args` — put the variable in the braces

Since Rust 1.58, format strings can capture variables by name directly: format!("{name}") instead of format!("{}", name). Clippy nudges you toward the inline form (this lint is in the style group; it is on by default in recent Clippy and shown here enabled explicitly so it always fires).

1
// before
2
fn uninlined(name: &str, age: u32) {
3
    println!("{} is {} years old", name, age);
4
}

Real Clippy output:

1
warning: variables can be used directly in the `format!` string
2
 --> src/main.rs:4:5
3
  |
4
4 |     println!("{} is {} years old", name, age);
5
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
8
help: change this to
9
  |
10
4 -     println!("{} is {} years old", name, age);
11
4 +     println!("{name} is {age} years old");
12
  |

1
// after
2
fn uninlined(name: &str, age: u32) {
3
    println!("{name} is {age} years old");
4
}

Note: Inline capture only works for bare identifiers in scope. format!("{}", user.name) cannot become format!("{user.name}") — field accesses and method calls still go in the trailing argument list. This is the same restriction as JavaScript template literals only being terse for simple ${name} substitutions.

`clone_on_copy` — you do not clone a number

Types that implement the Copy trait (i32, f64, bool, char, small #[derive(Copy)] structs) are copied implicitly on assignment. Calling .clone() on them is harmless but redundant, and signals you have not internalized the Copy vs Clone distinction yet.

1
// before
2
fn clone_on_copy() -> i32 {
3
    let x: i32 = 5;
4
    x.clone()
5
}

Real Clippy output:

1
warning: using `clone` on type `i32` which implements the `Copy` trait
2
 --> src/main.rs:3:5
3
  |
4
3 |     x.clone()
5
  |     ^^^^^^^^^ help: try removing the `clone` call: `x`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy
8
  = note: `#[warn(clippy::clone_on_copy)]` on by default

1
// after
2
fn clone_on_copy() -> i32 {
3
    let x: i32 = 5;
4
    x
5
}

`len_zero` — use `is_empty()`

x.len() == 0 works, but x.is_empty() is clearer and, for some types, cheaper (it does not have to compute the full length). This is the Rust analogue of the lint family that pushes JavaScript toward array.length === 0 checks being written consistently.

1
// before
2
fn len_zero(v: &[i32]) -> bool {
3
    v.len() == 0
4
}

Real Clippy output:

1
warning: length comparison to zero
2
 --> src/main.rs:2:5
3
  |
4
2 |     v.len() == 0
5
  |     ^^^^^^^^^^^^ help: using `is_empty` is clearer and more explicit: `v.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

1
// after
2
fn len_zero(v: &[i32]) -> bool {
3
    v.is_empty()
4
}

`map_clone` — use `.cloned()` (or `.copied()`)

iter().map(|x| x.clone()) is so common that there is a dedicated adapter: .cloned() for Clone types, .copied() for Copy types. It is shorter and reads as “give me owned values”.

1
// before
2
fn map_clone(v: &[String]) -> Vec<String> {
3
    v.iter().map(|s| s.clone()).collect()
4
}

Real Clippy output:

1
warning: you are using an explicit closure for cloning elements
2
  --> src/main.rs:10:5
3
   |
4
10 |     v.iter().map(|s| s.clone()).collect()
5
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider calling the dedicated `cloned` method: `v.iter().cloned()`
6
   |
7
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#map_clone
8
   = note: `#[warn(clippy::map_clone)]` on by default

1
// after
2
fn map_clone(v: &[String]) -> Vec<String> {
3
    v.iter().cloned().collect()
4
}

`ptr_arg` — take `&str`, not `&String`; `&[T]`, not `&Vec<T>`

A function that only reads a string should accept &str, and one that reads a list should accept &[T]. These “slice” types accept more callers (a &String coerces to &str for free, but not vice versa) and avoid a layer of indirection. This is one of the most important ergonomic lessons for newcomers.

1
// before
2
fn first_word(s: &String) -> &str {
3
    s.split(' ').next().unwrap_or("")
4
}

Real Clippy output:

1
warning: writing `&String` instead of `&str` involves a new object where a slice will do
2
 --> src/main.rs:9:17
3
  |
4
9 | fn redundant(s: &String) -> usize {
5
  |                 ^^^^^^^ help: change this to: `&str`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg
8
  = note: `#[warn(clippy::ptr_arg)]` on by default

1
// after
2
fn first_word(s: &str) -> &str {
3
    s.split(' ').next().unwrap_or("")
4
}

`needless_borrow` — drop the extra `&`

Method resolution auto-references for you, so (&s).len() is just s.len(). Writing the explicit & is the kind of habit you pick up from fighting the borrow checker and then never unlearn.

1
// before
2
fn needless_borrow(s: &str) {
3
    println!("{}", (&s).len());
4
}

Real Clippy output:

1
warning: this expression creates a reference which is immediately dereferenced by the compiler
2
  --> src/main.rs:14:20
3
   |
4
14 |     println!("{}", (&s).len());
5
   |                    ^^^^ help: change this to: `s`
6
   |
7
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
8
   = note: `#[warn(clippy::needless_borrow)]` on by default

1
// after
2
fn needless_borrow(s: &str) {
3
    println!("{}", s.len());
4
}

`unwrap_or_default` — let the type provide its default

option.unwrap_or(String::new()) constructs an empty String whose only purpose is to be the fallback. Default::default() is exactly that value, and .unwrap_or_default() expresses the intent directly.

1
// before
2
fn or_fun_call(o: Option<String>) -> String {
3
    o.unwrap_or(String::new())
4
}

Real Clippy output:

1
warning: use of `unwrap_or` to construct default value
2
 --> src/main.rs:6:7
3
  |
4
6 |     o.unwrap_or(String::new())
5
  |       ^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unwrap_or_default
8
  = note: `#[warn(clippy::unwrap_or_default)]` on by default

1
// after
2
fn or_fun_call(o: Option<String>) -> String {
3
    o.unwrap_or_default()
4
}

`or_fun_call` — `unwrap_or_else` is lazy, `unwrap_or` is eager

This is the most behaviorally significant lint in this list, and the most important one for a JavaScript developer to internalize. unwrap_or(x) evaluates x eagerly — before it knows whether the Option is Some. So o.unwrap_or(expensive()) runs expensive() every time, even when its result is thrown away. unwrap_or_else(|| expensive()) is lazy: the closure only runs on the None branch. (This is the same eager-vs-lazy trap as JavaScript’s a ?? defaultExpr always evaluating defaultExpr, versus wrapping it in a function.)

1
// before
2
fn lookup(o: Option<&str>) -> String {
3
    o.map(str::to_string).unwrap_or(String::from("anonymous"))
4
}

Real Clippy output:

1
warning: function call inside of `unwrap_or`
2
 --> src/main.rs:4:27
3
  |
4
4 |     o.map(str::to_string).unwrap_or(String::from("anonymous"))
5
  |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_else(|| String::from("anonymous"))`
6
  |
7
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#or_fun_call
8
  = note: `#[warn(clippy::or_fun_call)]`

1
// after
2
fn lookup(o: Option<&str>) -> String {
3
    o.map(str::to_string)
4
        .unwrap_or_else(|| String::from("anonymous"))
5
}

`redundant_clone` — you cloned, then dropped the original anyway

This lint (in the nursery/pedantic family) does real ownership analysis: if you clone() a value and the original is never used again, the clone was pointless — you could have moved the original. Cloning is one of the most common ways newcomers “make the borrow checker happy” without realizing it costs a heap allocation.

1
// before
2
fn process(data: Vec<i32>) -> i32 {
3
    let copy = data.clone();
4
    copy.iter().sum()
5
}

Real Clippy output (with #![warn(clippy::redundant_clone)]):

1
warning: redundant clone
2
 --> src/main.rs:4:20
3
  |
4
4 |     let copy = data.clone();
5
  |                    ^^^^^^^^ help: remove this
6
  |
7
note: this value is dropped without further use
8
 --> src/main.rs:4:16
9
  |
10
4 |     let copy = data.clone();
11
  |                ^^^^
12
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_clone

1
// after
2
fn process(data: Vec<i32>) -> i32 {
3
    data.iter().sum()
4
}

`needless_range_loop` and `manual_map` — let iterators do the work

Two more “write it the idiomatic way” lints. for i in 0..v.len() { ... v[i] ... } is the C-style index loop; Rust prefers iterating the collection directly. And a match that maps Some(x) => Some(f(x)) / None => None is exactly what Option::map does.

1
// before
2
fn needless_range_loop(v: &[i32]) {
3
    for i in 0..v.len() {
4
        println!("{}", v[i]);
5
    }
6
}
7

8
fn manual_map(o: Option<i32>) -> Option<i32> {
9
    match o {
10
        Some(x) => Some(x + 1),
11
        None => None,
12
    }
13
}

Real Clippy output:

1
warning: the loop variable `i` is only used to index `v`
2
  --> src/main.rs:18:14
3
   |
4
18 |     for i in 0..v.len() {
5
   |              ^^^^^^^^^^
6
   |
7
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_range_loop
8
   = note: `#[warn(clippy::needless_range_loop)]` on by default
9
help: consider using an iterator
10
   |
11
18 -     for i in 0..v.len() {
12
18 +     for <item> in &v {
13
   |
14

15
warning: manual implementation of `Option::map`
16
  --> src/main.rs:24:5
17
   |
18
24 | /     match o {
19
25 | |         Some(x) => Some(x + 1),
20
26 | |         None => None,
21
27 | |     }
22
   | |_____^ help: try: `o.map(|x| x + 1)`
23
   |
24
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_map
25
   = note: `#[warn(clippy::manual_map)]` on by default

1
// after
2
fn needless_range_loop(v: &[i32]) {
3
    for item in v {
4
        println!("{item}");
5
    }
6
}
7

8
fn manual_map(o: Option<i32>) -> Option<i32> {
9
    o.map(|x| x + 1)
10
}

A few more you will meet quickly

Lint	Flags	Fix
`redundant_field_names`	`P { name: name }`	`P { name }` (struct field shorthand, like JS `{ name }`)
`bool_comparison`	`if flag == true`	`if flag`
`collapsible_if`	`if a { if b { .. } }`	`if a && b { .. }`
`let_and_return`	`let w = f(); w`	`f()`
`redundant_closure`	`.map(	x
`single_char_pattern`	`s.split("x")`	`s.split('x')` (a `char`, not a one-char `&str`)

Key Differences

Aspect	ESLint / typescript-eslint	Clippy
Suggestions	Some rules autofixable (`--fix`)	Most lints are machine-applicable; `cargo clippy --fix` rewrites them
Type awareness	Needs `@typescript-eslint` + type info	Always has full type + borrow info (it runs inside the compiler)
Categories	`recommended`, plugin presets	Groups: `correctness` (deny), `style`, `complexity`, `perf`, `suspicious`, `pedantic`, `nursery`, `cargo`
Default strictness	Off until configured	`correctness`/`style`/`complexity`/`perf`/`suspicious` are on by default; `pedantic`/`nursery`/`cargo` are opt-in
Behavioral lints	Rare	`or_fun_call` and `redundant_clone` change runtime cost/behavior, not just style
Lint reference	Per-rule docs pages	Every warning links to `rust-lang.github.io/rust-clippy`

The single biggest mental shift: in ESLint, most rules are pure style. In Clippy, a large fraction of the default lints are about correctness and cost because they leverage the type system and ownership analysis. clone_on_copy, redundant_clone, and or_fun_call exist because Clippy can see that a heap allocation or eager evaluation is unnecessary — something a syntactic linter could never know.

Note: Clippy’s correctness group is set to deny by default — those lints catch likely bugs (e.g. # [derive(Hash)] with a manual PartialEq), so they fail the build, not just warn. The other default groups warn. See linting.md for adjusting these levels.

Common Pitfalls

1. Treating every Clippy warning as gospel

Clippy is heuristic. A suggestion can be a wash for readability, or occasionally wrong for your context. The fix is not to disable Clippy but to allow the specific lint at the narrowest scope with a comment explaining why:

1
// A dot product genuinely needs the index to pair two parallel slices,
2
// so the range loop is intentional here.
3
#[allow(clippy::needless_range_loop)] // index pairs `a[i]` with `b[i]`
4
fn dot(a: &[f64], b: &[f64]) -> f64 {
5
    let mut sum = 0.0;
6
    for i in 0..a.len() {
7
        sum += a[i] * b[i];
8
    }
9
    sum
10
}

This compiles with no warnings and documents the deviation. (The truly idiomatic version is a.iter().zip(b).map(|(x, y)| x * y).sum(), but the point stands: scoped allow beats globally disabling a lint.)

2. Blindly running `cargo clippy --fix` and not reading the diff

--fix is great, but a few lints (notably or_fun_call) change semantics from eager to lazy evaluation. That is almost always what you want — but you should still review the diff, the same way you would review a large ESLint --fix autofix. Run it on a clean working tree so git diff shows exactly what changed:

1
git status                         # make sure the tree is clean first
2
cargo clippy --fix                 # rewrites the source in place
3
git diff                           # review every change

3. Confusing `unwrap_or` (eager) with `unwrap_or_else` (lazy)

The classic real bug: cache.get(key).unwrap_or(load_from_disk(key)) hits the disk on every call, cache hit or not, because the argument to unwrap_or is evaluated before the lookup result is known. This is the same footgun as JavaScript’s cache.get(key) ?? loadFromDisk(key) always calling loadFromDisk. Clippy’s or_fun_call catches the common shapes, but not all of them — understand the rule, do not rely on the lint to always fire.

4. Expecting `pedantic`/`nursery` lints by default

cargo clippy does not run the pedantic, nursery, or cargo groups. If a tutorial shows redundant_clone or cast_precision_loss firing, they enabled it. Opt in per crate or per run:

1
cargo clippy -- -W clippy::pedantic        # one run

1
// or at the top of lib.rs / main.rs, for the whole crate
2
#![warn(clippy::pedantic)]

Warning: clippy::pedantic is intentionally noisy — it includes subjective lints like cast_precision_loss and module_name_repetitions. Enable it, then #![allow(...)] the handful you disagree with, rather than leaving it off entirely. See linting.md for the recommended baseline.

Best Practices

Run Clippy in CI with -D warnings so a regression fails the build, not just scrolls past in a log. See ci-cd.md and github-actions.md.
Terminal window
```
1
cargo clippy --all-targets --all-features -- -D warnings
```
Read the lint name and visit its docs page before silencing it. Every lint at rust-lang.github.io/rust-clippy explains why it exists and gives a “Known problems” section listing false positives.
Prefer narrow #[allow(...)] with a justifying comment over disabling a lint crate-wide. A reviewer should be able to see why the deviation is intentional.
Turn on clippy::pedantic early in a new project, while the codebase is small, and curate the allows. Retrofitting it onto a large crate is a slog.
Let cargo clippy --fix do the boring rewrites, then commit those separately from logic changes so the diff is easy to review.
Internalize the category of each lint. The perf and the behavioral lints (redundant_clone, or_fun_call, map_clone) teach you how Rust wants you to manage ownership and allocation; the style ones just teach you Rust’s surface idioms.

Real-World Example

A small log-parsing utility, written the “first draft” way and then cleaned up using Clippy. The first version compiles and runs, but earns a stack of warnings.

1
// src/main.rs — first draft, before Clippy
2
#[derive(Debug)]
3
struct LogLine {
4
    level: String,
5
    message: String,
6
}
7

8
fn parse(raw: &Vec<String>) -> Vec<LogLine> {
9
    let mut out: Vec<LogLine> = Vec::new();
10
    for i in 0..raw.len() {
11
        let line = raw[i].clone();
12
        if line.len() == 0 {
13
            continue;
14
        }
15
        let parts: Vec<String> = line.split(' ').map(|p| p.to_string()).collect();
16
        let level = parts.get(0).cloned().unwrap_or(String::from("INFO"));
17
        let message = parts[1..].join(" ");
18
        out.push(LogLine { level: level, message: message });
19
    }
20
    return out;
21
}
22

23
fn main() {
24
    let raw = vec![
25
        String::from("ERROR disk full"),
26
        String::from(""),
27
        String::from("INFO started"),
28
    ];
29
    for line in parse(&raw) {
30
        println!("[{}] {}", line.level, line.message);
31
    }
32
}

Running cargo clippy flags ptr_arg (&Vec<String> → &[String]), needless_range_loop, len_zero, get(0) → first(), unwrap_or constructing a default, redundant_field_names, and needless_return. After taking the suggestions (and inlining the format args), the cleaned-up version is Clippy-clean under clippy::all:

1
// src/main.rs — after Clippy. Clean under `cargo clippy -- -W clippy::all`.
2
#[derive(Debug)]
3
struct LogLine {
4
    level: String,
5
    message: String,
6
}
7

8
fn parse(raw: &[String]) -> Vec<LogLine> {
9
    let mut out: Vec<LogLine> = Vec::new();
10
    for line in raw {
11
        if line.is_empty() {
12
            continue;
13
        }
14
        let parts: Vec<&str> = line.split(' ').collect();
15
        let level = parts.first().map_or("INFO", |p| *p).to_string();
16
        let message = parts[1..].join(" ");
17
        out.push(LogLine { level, message });
18
    }
19
    out
20
}
21

22
fn main() {
23
    let raw = vec![
24
        String::from("ERROR disk full"),
25
        String::from(""),
26
        String::from("INFO started"),
27
    ];
28
    for line in parse(&raw) {
29
        println!("[{}] {}", line.level, line.message);
30
    }
31
}

It prints:

1
[ERROR] disk full
2
[INFO] started

The cleaned-up version is not just shorter — it allocates less (no per-line .clone(), no Vec<String> of split parts when Vec<&str> will do) and reads more like idiomatic Rust. That is the real payoff: Clippy is a teacher that nudges you from “Rust that works” toward “Rust the way Rust developers write it”.

Exercises

Exercise 1 — Take the suggestions

Difficulty: Beginner

Objective: Practice reading Clippy output and applying the fix.

Instructions: In a fresh cargo new project, paste the function below into src/main.rs, run cargo clippy, and rewrite the function so it produces zero warnings. The function returns the first character of each name.

1
fn initials(names: &Vec<String>) -> Vec<char> {
2
    let mut out: Vec<char> = Vec::new();
3
    for i in 0..names.len() {
4
        let name = names[i].clone();
5
        match name.chars().next() {
6
            Some(c) => out.push(c),
7
            None => {}
8
        }
9
    }
10
    return out;
11
}

Solution

Clippy flags ptr_arg (&Vec<String>), needless_range_loop, the redundant .clone(), the match that should be a filter_map, and needless_return. The idiomatic version:

1
// Clean under `cargo clippy`. Verified output below.
2
fn initials(names: &[String]) -> Vec<char> {
3
    names
4
        .iter()
5
        .filter_map(|n| n.chars().next())
6
        .collect()
7
}
8

9
fn main() {
10
    let names = vec![String::from("Ann"), String::from("Bob")];
11
    println!("{:?}", initials(&names));
12
}

Running it prints:

1
['A', 'B']

Exercise 2 — Eager vs lazy

Difficulty: Intermediate

Objective: Understand why or_fun_call matters, not just how to silence it.

Instructions: The function below uses unwrap_or with a function call. (1) Explain in one sentence what is wrong with it from a performance standpoint. (2) Rewrite it so slow_default() is only called when the Option is None. (3) Add a println! inside slow_default and confirm by running that the Some case never calls it.

1
fn slow_default() -> String {
2
    // imagine this hits the network
3
    String::from("fallback")
4
}
5

6
fn resolve(o: Option<String>) -> String {
7
    o.unwrap_or(slow_default())
8
}

Solution

(1) unwrap_or(slow_default()) evaluates slow_default() eagerly, every call — even when o is Some and the result is discarded. (2) Use the lazy unwrap_or_else with a closure. (3) The instrumentation confirms it.

1
fn slow_default() -> String {
2
    println!("slow_default() was called");
3
    String::from("fallback")
4
}
5

6
fn resolve(o: Option<String>) -> String {
7
    o.unwrap_or_else(slow_default)
8
}
9

10
fn main() {
11
    // Some case: slow_default must NOT be called.
12
    println!("{}", resolve(Some(String::from("cached"))));
13
    // None case: slow_default IS called.
14
    println!("{}", resolve(None));
15
}

Running it prints (note slow_default() was called appears only once, for the None case):

1
cached
2
slow_default() was called
3
fallback

Passing slow_default directly (instead of || slow_default()) also satisfies Clippy’s redundant_closure lint.

Exercise 3 — Tame `pedantic`

Difficulty: Advanced

Objective: Refactor an imperative function into idiomatic iterator style and survive clippy::pedantic.

Instructions: Add #![warn(clippy::pedantic)] to the top of src/main.rs, paste the code below, run cargo clippy, and resolve every warning. active_names should return the names of active users; average_active_age should return the average age of active users, or None if there are none. One of the warnings is a cast_precision_loss from pedantic — decide whether to restructure the code to avoid the cast or to #[allow] it with a justification.

1
#[derive(Debug, Clone)]
2
struct User {
3
    name: String,
4
    active: bool,
5
    age: u32,
6
}
7

8
fn active_names(users: &Vec<User>) -> Vec<String> {
9
    let mut out = Vec::new();
10
    for i in 0..users.len() {
11
        if users[i].active == true {
12
            out.push(users[i].name.clone());
13
        }
14
    }
15
    return out;
16
}
17

18
fn average_active_age(users: &Vec<User>) -> Option<f64> {
19
    let mut total = 0;
20
    let mut n = 0;
21
    for u in users {
22
        if u.active {
23
            total += u.age;
24
            n += 1;
25
        }
26
    }
27
    if n == 0 {
28
        return None;
29
    }
30
    return Some(total as f64 / n as f64);
31
}

Solution

This is clean under cargo clippy -- -W clippy::all (the default groups). The cast_precision_loss warning only appears under pedantic; here we keep the cast but it is justified by n being a small count, so a scoped #[allow] with a comment is the pragmatic choice.

1
#[derive(Debug, Clone)]
2
struct User {
3
    name: String,
4
    active: bool,
5
    age: u32,
6
}
7

8
fn active_names(users: &[User]) -> Vec<String> {
9
    users
10
        .iter()
11
        .filter(|u| u.active)
12
        .map(|u| u.name.clone())
13
        .collect()
14
}
15

16
#[allow(clippy::cast_precision_loss)] // counts are small; f64 is exact here
17
fn average_active_age(users: &[User]) -> Option<f64> {
18
    let ages: Vec<u32> = users.iter().filter(|u| u.active).map(|u| u.age).collect();
19
    if ages.is_empty() {
20
        return None;
21
    }
22
    let total: u32 = ages.iter().sum();
23
    Some(f64::from(total) / ages.len() as f64)
24
}
25

26
fn main() {
27
    let users = vec![
28
        User { name: String::from("Ann"), active: true, age: 30 },
29
        User { name: String::from("Bob"), active: false, age: 40 },
30
        User { name: String::from("Cy"), active: true, age: 50 },
31
    ];
32
    println!("{:?}", active_names(&users));
33
    println!("{:?}", average_active_age(&users));
34
}

Running it prints:

1
["Ann", "Cy"]
2
Some(40.0)

Fixes applied: ptr_arg (&Vec<User> → &[User]), needless_range_loop, bool_comparison (== true), the redundant .clone() pattern moved into a clean map, and needless_return.

Common Clippy Lints, Explained

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

needless_return — drop the trailing return

uninlined_format_args — put the variable in the braces

clone_on_copy — you do not clone a number

len_zero — use is_empty()

map_clone — use .cloned() (or .copied())

ptr_arg — take &str, not &String; &[T], not &Vec<T>

needless_borrow — drop the extra &

unwrap_or_default — let the type provide its default

or_fun_call — unwrap_or_else is lazy, unwrap_or is eager

redundant_clone — you cloned, then dropped the original anyway

needless_range_loop and manual_map — let iterators do the work

A few more you will meet quickly

Key Differences

Common Pitfalls

1. Treating every Clippy warning as gospel

2. Blindly running cargo clippy --fix and not reading the diff

3. Confusing unwrap_or (eager) with unwrap_or_else (lazy)

4. Expecting pedantic/nursery lints by default

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1 — Take the suggestions

Exercise 2 — Eager vs lazy

Exercise 3 — Tame pedantic

`needless_return` — drop the trailing `return`

`uninlined_format_args` — put the variable in the braces

`clone_on_copy` — you do not clone a number

`len_zero` — use `is_empty()`

`map_clone` — use `.cloned()` (or `.copied()`)

`ptr_arg` — take `&str`, not `&String`; `&[T]`, not `&Vec<T>`

`needless_borrow` — drop the extra `&`

`unwrap_or_default` — let the type provide its default

`or_fun_call` — `unwrap_or_else` is lazy, `unwrap_or` is eager

`redundant_clone` — you cloned, then dropped the original anyway

`needless_range_loop` and `manual_map` — let iterators do the work

2. Blindly running `cargo clippy --fix` and not reading the diff

3. Confusing `unwrap_or` (eager) with `unwrap_or_else` (lazy)

4. Expecting `pedantic`/`nursery` lints by default

Exercise 3 — Tame `pedantic`