Clippy lints / Complexity
Clippy lint · Complexity · checked with Clippy 0.1.99
clippy::manual_split_once: Checks for usage of str::splitn(2, _)
What it meansChecks for usage of str::splitn(2, _) It is in the complexity group and warns by default.
Does it matter?
split_once is both clearer in intent and slightly more efficient.
Code that does something simple in a complicated way. Warns by default.
How to fix it
Clippy can fix this one for you: run cargo clippy --fix (add --allow-dirty if you have uncommitted changes). Review the diff before you commit.
Flagged
let s = "key=value=add";
let (key, value) = s.splitn(2, '=').next_tuple()?;
let value = s.splitn(2, '=').nth(1)?;
let mut parts = s.splitn(2, '=');
let key = parts.next()?;
let value = parts.next()?;
Write this instead
let s = "key=value=add";
let (key, value) = s.split_once('=')?;
let value = s.split_once('=')?.1;
let (key, value) = s.split_once('=')?;
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::manual_split_once)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
manual_split_once = "allow"One run
cargo clippy -- -A clippy::manual-split-onceThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Settings in clippy.toml
msrv: The minimum rust version that the project supports. Defaults to the rust-version field in Cargo.toml
Clippy's own documentation
What it does
Checks for usage of str::splitn(2, _)
Why is this bad?
split_once is both clearer in intent and slightly more efficient.
Example
let s = "key=value=add";
let (key, value) = s.splitn(2, '=').next_tuple()?;
let value = s.splitn(2, '=').nth(1)?;
let mut parts = s.splitn(2, '=');
let key = parts.next()?;
let value = parts.next()?;
Use instead:
let s = "key=value=add";
let (key, value) = s.split_once('=')?;
let value = s.split_once('=')?.1;
let (key, value) = s.split_once('=')?;
Limitations
The multiple statement variant currently only detects iter.next()?/iter.next().unwrap()
in two separate let statements that immediately follow the splitn()
Configuration
-
msrv: The minimum rust version that the project supports. Defaults to therust-versionfield inCargo.toml(default:
current version)
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- too_many_argumentsChecks for functions with too many parameters
- clone_on_copyusing `clone` on type `u64` which implements the `Copy` trait
- type_complexityChecks for types used in structs, parameters and let declarations above a certain complexity threshold
- manual_range_patternsthis OR pattern can be rewritten using a range
- manual_rem_euclidmanual `rem_euclid` implementation
- manual_slice_size_calculationWhen a is &[T], detect a.len() * size_of::<T>() and suggest size_of_val(a) instead
- manual_stripstripping a prefix manually
- manual_swapthis looks like you are swapping `b` and `a` manually
- manual_takemanual implementation of `mem::take`
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::too_many_argumentsChecks for functions with too many parametersRead it next →Did this answer your question?