-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Open
Labels
A-lintArea: New lintsArea: New lintsL-styleLint: Belongs in the style lint groupLint: Belongs in the style lint groupT-middleType: Probably requires verifiying typesType: Probably requires verifiying typesgood first issueThese issues are a good way to get started with ClippyThese issues are a good way to get started with Clippy
Metadata
Metadata
Assignees
Labels
A-lintArea: New lintsArea: New lintsL-styleLint: Belongs in the style lint groupLint: Belongs in the style lint groupT-middleType: Probably requires verifiying typesType: Probably requires verifiying typesgood first issueThese issues are a good way to get started with ClippyThese issues are a good way to get started with Clippy
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
0xazure commentedon Nov 20, 2018
Hey @oli-obk I'm interested in having a go at implementing this lint. Is it still up for grabs?
Manishearth commentedon Nov 20, 2018
Actually, I'm not sure if this really is valid rust style -- setters and getters may be added to future proof an API, for example.
0xazure commentedon Nov 20, 2018
That's a really good point, I can definitely see that use case.
That would also nix linting if it only has a
get_foo
since the setter might be implemented at a later date.Move to close this?
hcpl commentedon Nov 20, 2018
The "If the type only has a
get_foo
method but not aset_foo
method, suggest naming itfoo
instead" part is still relevant IMO, so I vote against.0xazure commentedon Nov 20, 2018
If we're considering the case of future-proofing an API, if the method named
foo
gets the value what should be done if a setter needs to be implemented at a later date? Thefoo
method would need to be renamedget_foo
beforeset_foo
is introduced, which I think breaks the same kind of compatibility as changing from public fields to methods @Manishearth pointed out.Maybe I'm missing something about the use case though, @hcpl do you have an example?
hcpl commentedon Nov 20, 2018
@0xazure yeah, for example,
std::net::SocketAddr
hasip
as the getter andset_ip
as the setter.Not sure if this particular instance is idiomatic by any means, but it shows that this naming scheme has a precedent in the standard library.
Also,
foo
doesn't need to be renamed:SocketAddr::ip()
was introduced in Rust 1.7.0 andSocketAddr::set_ip()
--- in Rust 1.9.0 (again, I don't know whether this was idiomatic or a workaround to keep backwards compatibility, but it works).0xazure commentedon Nov 20, 2018
Thanks for the example, @hcpl!
I don't think it's idiomatic, but it looks like
ip
was stabilized in1.7.0
andset_ip
was stabilized later in1.9.0
(it also looks likeport
andset_port
from that same enum follow the same pattern).This proves the point of future-proofing though;
ip
couldn't be renamedget_ip
whenset_ip
was introduced, so it should have been namedget_ip
in the first place. However, naming itget_ip
would not pass the proposed lint because at the time there was no correspondingset_ip
method so the lint would suggest naming itip
instead.hcpl commentedon Nov 20, 2018
Personally, I find the
get_foo
/set_foo
naming scheme less pleasant thanfoo
/set_foo
because when reading codefoo
/set_foo
having different lengths makes them more visually distinct thanget_foo
/set_foo
which only differ in the first letter. Also I tend to access data more than modify in my code so withfoo
I have to type less, but since code tends to be read more than written, that's a minor point compared to the previous one.And I just found this in API guidelines: https://rust-lang-nursery.github.io/api-guidelines/naming.html#c-getter. Curiously, setters aren't mentioned anywhere in the guidelines (would be good to notify maintainers over there about this topic).
0xazure commentedon Nov 20, 2018
I don't personally have any preference for
get_foo
/set_foo
overfoo/set_foo
, I think the consistency is more important.That API Guidelines section is a great find!
Based on that section the
ip
/set_ip
naming is intentional, and I've turned up a bunch more examples instd::fs
likelen
/set_len
,permissions
/set_permissions
, etc.It looks like we should lint to disallow
get_
prefixes, especially if there's a matchingset_
method, though I'm not 100% sure how we'd want to go about allowing the special cases as inCell::get
andget_mut
orget_unchecked
unless those are the only casesget
appears.flip1995 commentedon Nov 20, 2018
Searching the std lib of rust for
get*
you can find the special casesget
get_mut
get_ref
get_unchecked
get_type_id
)and combinations of the functions above.
I think we can add a
style
lint for getters prefixed withget_
, that aren't one of the special cases above and link to the API guidelines in the documentation of the lint.0xazure commentedon Nov 20, 2018
get_type_id
stabilization is tracked as rust-lang/rust#27745, there's a comment noting it could be renamed totype_id
so I think it's an outlier in this case.flip1995 commentedon Nov 21, 2018
Yes I don't think this should be included in the special cases, just listed it for completeness.
Merge #122
0xazure commentedon Nov 23, 2018
To summarize, if the type has a
get_foo
method we should suggest naming itfoo
instead to follow the API Guidelines for Rust getter name conventions except for cases of:get
get_mut
get_unchecked
get_unchecked_mut
get_ref
This should be enough to get me started on a style lint for this convention, I should have some time over the next couple days to start digging into this.
flip1995 commentedon Nov 23, 2018
Exactly! It shouldn't be required to explicitly filter
get_unchecked_mut
when already filteringget_unchecked
, if you check for prefixes.0xazure commentedon Nov 23, 2018
I think that's an interesting question, should we lint for only the prefixes (e.g.
get_mut*
,get_unchecked*
)? I foresee the potential for method names likeget_unchecked_foo_bar
orget_reference_for_foo
that would pass a test for only the prefixes.flip1995 commentedon Nov 23, 2018
Yeah this methods would pass the lint. But is this bad?
get_unchecked_foo
vs.foo_unchecked
: I'm not sure what I'd prefer. I tend to the former sinceget_unchecked
is common in rust.0xazure commentedon Dec 11, 2018
Just wanted to post an update, I'm still working on this but have other demands on my time right now. I should get back to it in a week or so, hopefully have a PR up soon after that.
Add getter prefix name lint
JanBerktold commentedon Nov 14, 2024
Would a lint that implements this rule still be accepted into clippy today? If so, I'm happy to pick this up.