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?

Bantam

Maybe it would be clearer if you quote the particular rule you are talking about. The one I found is definitely bad for encapsulation. – Namangan

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.

Sustain

But why should the "accessors" have the same name as the variables thay acces, and what happens if these variables get removed? As soon as you take advantage of encapsulation to change the inner workings of your class, you start breaking the rules. – Namangan

@juanchopanza: that's true of course. Presumably the practical solution used by Google programmers is the obvious one: you name the accessor and the member variable to match, and then if you later change the inner workings you leave the documented public interface alone. – Xanthin

@SteveJessop Yeah, I'm sure they are pragmatical about this. I've heard they know a thing or two about software too. – Namangan

@juanchopanza: when I've asked Googlers about their coding style, they've tended to respond along the lines that it's mostly useful and if not everyone's smart enough that they can live with it anyway. If they had nothing more interesting to worry about than this, I'm pretty sure the 3 I know who I've worked with before, wouldn't still be there ;-) – Xanthin

@Namangan Just a guess, but when they speak of attributes, presumably, they are talking about the externally visible aspects of the class, and not implementation details of whether it has a variable or not. – Relativity

@JamesKanze: well, they say "accessors and mutators match the name of the variable". Maybe by "variable" then mean "attribute" in a generic sense but I think they probably intended to mean "non-static data member" ;-) – Xanthin

@SteveJessop Having read more of their coding guidelines: you could be right. They do seem to ignore design issues completely. But I can't be sure. And I do think it reasonable to distinguish between accessing what are conceptually attributes and other functions. (Some languages go so far as to provide a separate syntax, and allow accessing attributes without using the parentheses.) – Relativity

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.

Loney

Forgive my ignorance, but how would one get the same behaviour as passing by reference? – Offertory

You did not answer the question... It is like saying "they do because they do" – Boleyn

@AndréPuel I guess the implication is that they have this rule because they like silly rules. In this particular case, I have to agree. – Namangan

@AndréPuel you're asking for the real reason for a silly rule? Do you consider "references are confusing" as a reason for not using references? If so, then sorry, I don't have a reason :) – Loney

@LuchianGrigore: be fair, though, you have misrepresented both the rule and its reason. Google's rule is not to pass outparams by non-const reference, and the exact sense in which it is considered confusing (i.e, the two different things that it is believed to confuse) is stated in the style guide. That's not to say it's right IMO, and I might even go so far as to agree that it's a bit silly, but it's not as silly as you're saying. e.g. they pass by const references happily. – Xanthin

I dont think it is a good reason, but I now understand why they did ban passing as reference. – Boleyn

Where do they forbid passing by reference? – Relativity

@JamesKanze: section "Reference Arguments", and they permit passing by reference-to-const. They don't specify how to write a swap function, but I have a slightly scary feeling that since they don't use exceptions, maybe they also don't bother with a unified form of swapping... – Xanthin

@SteveJessop They don't allow references to non-const. That's something different from not allowing references. There's a legitimate argument for using pointers for out parameters. My personal preferences would use non-const references, but it's really a somewhat arbitrary choice; you choose to distinguish something else. (Of course, in my opinion, out parameters should be relatively rare, and the name of the function should make it clear when they're there.) – Relativity

@JamesKanze: I agree with all that, including the part in parens. I already grumbled at Luchian for mis-stating the rule. – Xanthin

@SteveJessop ah, sorry, un-intentional, I assure you. I read them a while back, just remembered they had a silly rule about references. – Loney

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.)

Relativity

I swear I will not take the opportunity to start an argument if you reply, but why is it a hard rule of your C++ style that names must not end in an underscore? Just that fact that bar and bar_ can be confused when the cursor lies after the r, or more to it than that? – Xanthin

@SteveJessop Readability. In the most basic sense: underscores can disappear visually, or easily be mistaken for a space. In fact, one of the reasons they're used internally is that the human eye sees a space at first view. – Relativity

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.

Xanthin