Lint `set_*` and `get_*` methods that do nothing but access the field

[oli-obk]

It is not idiomatic in Rust to have setters and getters. Make the field public instead.

If the type only has a get_foo method but not a set_foo method, suggest naming it foo instead.

[0xazure]

Hey @oli-obk I'm interested in having a go at implementing this lint. Is it still up for grabs?

[Manishearth]

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]

future proof an API

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]

Move to close this?

The "If the type only has a get_foo method but not a set_foo method, suggest naming it foo instead" part is still relevant IMO, so I vote against.

[0xazure]

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? The foo method would need to be renamed get_foo before set_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]

@0xazure yeah, for example, std::net::SocketAddr has ip as the getter and set_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 and SocketAddr::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]

Thanks for the example, @hcpl!

I don't think it's idiomatic, but it looks like ip was stabilized in 1.7.0 and set_ip was stabilized later in 1.9.0 (it also looks like port and set_port from that same enum follow the same pattern).

This proves the point of future-proofing though; ip couldn't be renamed get_ip when set_ip was introduced, so it should have been named get_ip in the first place. However, naming it get_ip would not pass the proposed lint because at the time there was no corresponding set_ip method so the lint would suggest naming it ip instead.

[hcpl]

Personally, I find the get_foo/set_foo naming scheme less pleasant than foo/set_foo because when reading code foo/set_foo having different lengths makes them more visually distinct than get_foo/set_foo which only differ in the first letter. Also I tend to access data more than modify in my code so with foo 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]

I don't personally have any preference for get_foo/set_foo over foo/set_foo, I think the consistency is more important.

That API Guidelines section is a great find!

With a few exceptions, the get_ prefix is not used for getters in Rust code.

Based on that section the ip/set_ip naming is intentional, and I've turned up a bunch more examples in std::fs like len/set_len, permissions/set_permissions, etc.

It looks like we should lint to disallow get_ prefixes, especially if there's a matching set_ method, though I'm not 100% sure how we'd want to go about allowing the special cases as in Cell::get and get_mut or get_unchecked unless those are the only cases get appears.

[flip1995]

Searching the std lib of rust for get* you can find the special cases

• get
• 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 with get_, that aren't one of the special cases above and link to the API guidelines in the documentation of the lint.