Variable naming: member identification vs ease of use

Question

I'm writing a little library for myself which has a class that contains hexfields with their cube coordinates x,y and z. Now I usually mark my member variables with a leading m, e.g. int mPosition; or mX, mY, mZ, in this specific case. This would lead to the getter being named getmX().

This is pretty straightforward, but is somehow not as readable as getX(). Would you say it is acceptable to use mX in the class, but rename the publically visible getter to getX()? Or is there a reason to stay consistent? There will not be a publically available setter.

Seems very subjective here. Personally, I think getX() or even getXCoord() would be fine to use. — Rubix Rechvin, May 28 '15 at 15:43
Usually, the getters and setters are constructed with `get`/`set` + VariableName. It's a pretty common convention — Alex Tartan, May 28 '15 at 15:43
Simple do what you or your company want but always in the same way. It really unimportant how you do it! — Klaus, May 28 '15 at 15:43
Hex fields is just the short form of hexagonal fields, commonly used in strategy games or role playing games. Since they have 6 neighbors you can't simply use x and y coordinates, instead you view them as arranged in a 3 dimensional cube and give them x,y and z coordinates. It's not relevant at all for the question, though :) — Draugr, May 28 '15 at 15:52

score 9 · Accepted Answer · answered May 28 '15 at 15:43

9

This would lead to the getter being named getmX().

No, it wouldn't.

The entity is "called" x.
The member variable you used to represent that entity is mX.
The getter function you used to access that entity is getX().

I wouldn't go too far down the path of getters and setters, though; they're a bit of an anti-pattern when only thinly wrapping individual variables like this.

Besides, call it whatever you want.

answered May 28 '15 at 15:43

Lightness Races in Orbit

378,754
76
643
1,055

Thanks, that makes a lot of sense to me. This ways I feel I get the most mileage for me and possibly other people having to use the code at some point. – Draugr May 28 '15 at 15:49
@Draugr: [This answer](http://stackoverflow.com/a/12108025/560648) is a good read. – Lightness Races in Orbit May 28 '15 at 15:51
Thanks, I'll have a look at that. – Draugr May 28 '15 at 15:55

score 1 · Answer 2 · answered May 28 '15 at 15:44

1

The fact that private variables have a leading m is an implementation detail, clients shouldn't rely on it.

Your getters are public and should never change even if you change your implementation. Therefore, it's not a question of being easy to use. You should write getX() for better encapsulation.

answered May 28 '15 at 15:44

KABoissonneault

2,359
18
17

1

_"You should write getX() for better encapsulation."_ huh – Lightness Races in Orbit May 28 '15 at 15:48
@LightnessRacesinOrbit Yes? Do you disagree? – KABoissonneault May 28 '15 at 15:48
I don't see what "encapsulation" has to do with it, is all. – Lightness Races in Orbit May 28 '15 at 15:49
@LightnessRacesinOrbit I'm just saying, if he's strict about naming his getters after the exact name of the member it's getting, then he can't change the name of the member variable without changing the signature of "getmX()". By naming the function "getX()", he can name his member however he wants and rename it without breaking client code – KABoissonneault May 28 '15 at 15:51
Sure, that makes sense. – Lightness Races in Orbit May 28 '15 at 15:55

Variable naming: member identification vs ease of use

2 Answers2