Why does Google name accessors and mutators after member variables?

Question

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Names#Function_Names

Regular functions have mixed case; accessors and mutators match the name of the variable: MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().

Isn't it the whole point of encapsulation to hide implementation details from the user so he/she is not aware of whether the accessor/mutator method returns/modifies a member variable or not? What if I change the variable name or change the way it's stored inside the object?

EDIT:

If I have an instance variable int foo_ it seems straightforward

int foo() const { return foo_; }

but if I add another method that returns foo_ + 2, should I name if bar or GetBar?

int bar() const { return foo_ + 2; }
int GetBar() const { return foo_ + 2; }

If I choose GetBar and later decide to cache the returned value in another member variable bar_, will I have to rename the method to bar?

Answer 1

Actually, the point of encapsulation is to hide the inner workings of a class, not necessarily to hide the names of things. The name of the member variable doesn't matter; it's the level of indirection that the accessor or mutator provides.

Having an accessor gives you the ability to change the inner workings of the class (including the names of member variables) without breaking the class's interface with the outside world. The user of the class need not concern himself with implementation details, including what things are named inside the class, but only on the behavior of the class, as seen from the outside.

To put it another way, users of a class should not rely on Google's style guide to determine whether or not they are modifying a member variable.

Answer 2

Because google style guide is only meant to be followed by google employees. Rather - it's not that good of a style guide.

Case in point - they explicitly ban passing by non-const reference because it can be "confusing".

So you're right, it defeats the purpose of encapsulation. Don't guide yourself by it.

Answer 3

When considering a class, it may conceptually have visible state, which can be accessed by the client. How this state is represented inside the class is another matter, and that's what accessors (getters and setters) hide. My own naming convention also makes this distinction: if the function is conceptually a getter or a setter, it has the name of the attribute, which would normally be a noun; otherwise, it is a verb. And I distinguish between cases where the function is getting or setting something which isn't conceptually part of the class (e.g. which partially depends on an argument), which have the verb get or set in their name, and the case where the function is actually modifying what is conceptually an attribute, in which case they don't.

For the rest, like most style guides, not everyone is in total agreement with this one. I'm not sure I like their naming conventions, for example. They're called naming conventions because they are just that: arbitrary conventions. The only real hard rule is that types, macros and other things must be distinguished, and that names should never start or end with an underscore. (There are also some softer rules: I'd be very suspicious of a convention which ended up making the names of local variables longer than those of globals.)

Answer 4

I may be taking an assumption of common sense too far, but I'm pretty sure that retaining a published interface takes precedence over following the naming guide.

Since your original bar / GetBar function is not an accessor, I presume it should follow the regular name guide and be called GetBar.

If you later introduce bar_ so that in some sense the function becomes an accessor, I'm pretty sure you should not remove GetBar. I suppose you could add a function bar() as well, defined to do the same thing, but I don't think I'd interpret the style guide to require that.

I'm also pretty sure that as soon as your published interface includes functions that you (and callers) think of as "accessors", encapsulation is in any case out the window to some extent, because you're talking about the state of the object instead of its behavior. Just because a function returns the value of a member variable in the current implementation does not mean that it has to be documented as an accessor. But if you do insist on writing functions that are publicly recognized as accessors, Google tells you how to name them. The classic example is that a sufficiently dumb data record object might reasonably have accessors, since the whole class is publicly defined to be a bundle of fields with maybe a little bit of behavior.

I've read that style guide a few times before, but I have never worked for Google so I'm not privy to how their code reviews tend to apply it in practice. I should think that an organization that size cannot be wholly consistent in every detail. So your guess is probably as good as mine.