Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convention for Naming Getters #89

Closed
theduke opened this issue May 31, 2017 · 5 comments
Closed

Convention for Naming Getters #89

theduke opened this issue May 31, 2017 · 5 comments
Labels
new guideline A proposed new guideline

Comments

@theduke
Copy link

theduke commented May 31, 2017

I noticed that the guidelines don't recommend a way to name getters.

fn get_member(&self) -> &Member

vs

fn member(&self) -> &Member

Might be nice to recommend something here.

I'd be strongly in favor of the second option without get_.

@sfackler
Copy link
Member

With very few exceptions (e.g. get_ref and get_mut), the get_ prefix is not used in Rust code.

@alteous
Copy link

alteous commented Aug 3, 2017

fn member(&self) -> &Member

Should be the preferred option.

@dtolnay dtolnay added the new guideline A proposed new guideline label Sep 18, 2017
@dtolnay
Copy link
Member

dtolnay commented Sep 18, 2017

Ideally the current "Single-element containers implement appropriate getters" guideline should be expanded to cover getters more generally.

@dtolnay
Copy link
Member

dtolnay commented Sep 18, 2017

Let's be sure to touch on the difference between conversions and accessors. As an example, TempDir::path is an accessor so it would not be correct to call it TempDir::as_path.

@dtolnay
Copy link
Member

dtolnay commented Oct 30, 2017

I generalized the explanation of getter naming in a80355d and added a note about getter vs conversion in 5ac0bd0.

@dtolnay dtolnay closed this as completed Oct 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new guideline A proposed new guideline
Projects
None yet
Development

No branches or pull requests

4 participants