`struct_field_names` triggers when the field name *is* the struct name

[marienz]

Summary

I'm not sure if this is an actual false positive (looks like changing >= to > here might stop it from firing) or it's just not clear to me (even after reading the lint description) why it thinks this is bad.

The lint description says it checks for prefixes / suffixes, and suggests I delete them. That makes sense to me.

But if the field name is the struct name I can't delete the entire name, I'd have to come up with a different one. I could see the point in suggesting that I use a newtype if I had no other fields, but the lint actually won't fire unless I do have other fields, so that doesn't apply either.

That leaves "come up with a different name". If there is value to that, I'd appreciate the lint description explaining it.

Issue #12922 is somewhat related (not just because it's the same lint): the first example there (app in struct App) would also be allowed if this was changed.

Lint Name

struct_field_names

Reproducer

I tried this code:

struct Map {
    map: Vec<Vec<i32>>,
    rows: usize,
    cols: usize,
}

I saw this happen:

warning: field name starts with the struct's name
  --> foo.rs:89:5
   |
89 |     map: Vec<Vec<i32>>,
   |     ^^^^^^^^^^^^^^^^^^
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#struct_field_names

I expected to see this happen:

Either no lint or a better explanation of why this is bad and what I should do instead.

Version

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

Additional Labels

No response

[alex-semenyuk]

I would say that this case mentioned at description
https://rust-lang.github.io/rust-clippy/master/index.html#struct_field_names

Detects struct fields that are prefixed or suffixed by the same characters or the name of the struct itself.

And explanation

Why is this bad?
Information common to all struct fields is better represented in the struct name.

[marienz]

Mentioned in the description: yes.

I don't understand the explanation. struct Map contains a map and some ancillary information. The only "information common to all struct fields" as I understand it is "it's all about a map", so I "represented" that "in the struct name" by calling it Map. But that's exactly what triggers the lint.

I don't understand what change the lint wants me to make. I don't see any additional information common to all struct fields that I can add to the struct name.

(The explanation makes perfect sense to me for the case of struct Foo containing fields foo_x, foo_y and so forth. In that case the "information common to all struct fields" (they're all "foo") is already "represented in the struct name", so the fix is to remove the duplication. But I can't do that here because my map field still needs a name.)

(Sidenote: I wonder if there's value in a lint looking for all field names in a struct having a common prefix like that that isn't the struct name and suggesting you remove it / move it to the struct name...)

I'd expect I'd have the same question in most if not all cases I'd trigger this with a field named exactly after the struct name (like the App example in the other issue I mentioned).

[edwloef]

I'm also hitting this case (and "allow"-ing this lint because of it), and am of the same opinion as marienz on name reasoning. Additionally, module_name_repetitions doesn't lint if a struct has the same name as its module, and it seems reasonable to see the lints as related.