This is really a nonsense topic, but I like nonsense sometimes....

I don't really do anything to differentiate my member variables from 'guest'* variables because I'm almost always the only one who ever sees my code, but my projects are growing bigger and bigger lately and it seems like a good time to address some coding conventions.

Everywhere seems to suggest some was of differentiating these variables - which makes perfect sense - but I'm wondering why we chose to do it to the member variables... It seems to me that, conceptually, an object should be most familiar with its own member variables - they're its member variables - and it is the external ones that need to be called out.

I mean, doesn't it make more sense to say

void someFunctionToIncrementMemberNum(int g_num) { num += g_num};

Rather than

void someFunctionToIncrementMemberNum(int num) { m_num += num};

I think that if I adopt this practice, I'll be doing it this way. I appreciate that convention means that no one will ever be working with me

*guest, visitor, stranger, outsider...

First of all, I don't think it's a nonsense topic :)

In the end I think it all depends on your preference and the team's 'playing rules'/ coding conventions. Personally I'm a prefix guy, all my members are prefixed with m, e.g. mWorldPos, mWorldMat etc. And function parameters for me are always pSomething (which can also be interpreted as pointer,but in my case it isn't perse :))

For all conventions, I think if it's in your system/ head, it helps. For me seeing mSomething is directly clear that it's a member variable (Without thinking about it), same for pSomething.

Personally, I find it important to always have specific sets of variables have the same prefix. That way, when someone is looking at your code, or you share your code, it is easily identifiable what variables perform what specific role. Now, you can pick your own convention but stick to it throughout your code. 

Plus, it is just good practice to conform to some coding etiquette that is normal throughout most programmers.

Thanks for the responses.

I wasn't specifically questioning why variables should be identified as belonging to the function - although the post title does suggest that. I was more asking why, by convention, is it the MEMBER variables that are called as opposed to the GUEST variables.

3 minutes ago, Tucker Langseth said:

Plus, it is just good practice to conform to some coding etiquette that is normal throughout most programmers.

It is indeed

I think it's very use-case specific which ones 'win' in logics to give them a prefix/convention, so I always do both. The tricky thing when you only apply it for example to member vars OR function parameters, how would you then distinguish local vars within member functions :)

Do people not normally do this?

Again, I don't really adopt this as a convention, but a lot of my code tends to have variables like:

value <- the definitive member variable

tempValue <- a temporary or intermediary variable

inValue <- the value passed as a parameter.

I assumed that would be normal.

*Obviously, I have more useful names than 'value'...

2 hours ago, SomeoneRichards said:

Do people not normally do this?

It depends on the team, if your team is mostly programmers I would say yes.

2 hours ago, SomeoneRichards said:

value <- the definitive member variable

tempValue <- a temporary or intermediary variable

inValue <- the value passed as a parameter.

In most of hobby projects I worked on we did the same as you are doing here.

On professional teams I have seen the member variable having some kind of prefix or indication. I think it can be because professional  projects have much more classes. So if a programmer opens a page, they are aware that they are editing a class because all the member variables indicate this.

The reason you identify members as opposed to locals or parameters is that they are not local to the method scope. 

if you have some free function

int add(int x, int y) => x+y;

It’s obvious where all the variables come from. On the other hand a method like 

void accelerate(int delta) => speed += delta;

Where does speed come from? Is it a global? Marking the scope eases the cognitive load. 

13 minutes ago, ChaosEngine said:

The reason you identify members as opposed to locals or parameters is that they are not local to the method scope. 

if you have some free function

int add(int x, int y) => x+y;

It’s obvious where all the variables come from. On the other hand a method like 

void accelerate(int delta) => speed += delta;

Where does speed come from? Is it a global? Marking the scope eases the cognitive load. 

Ahhh. I was focusing on member vs non-member variables... I hadn't considered the wider picture of member and non-member functions - which is odd because almost all of my functions are declared outside of structs...

You are completely correct and that makes perfect sense. Thank you.

Since global variables are for the most part a bad idea, you should probably call them out where necessary by namespacing them.  Maybe prefixing a "g_" (or if in C++, using their fully-qualified name) is a good practice.

The case for namespacing member variable inside a member function comes more from distinguishing the object state from the local state.  If you qualify the member variables with a prefix (eg. m_, this->) or suffix (_) you know when you're mutating object state as opposed to local function state.  That's the fundamental argument for obfuscating your variables this way.

Fewer warts in your code is better.  Sure, it satisfies the CDOP (ie. OCPD in proper alphabetical order) in many developers to categorize and neatly label their variables, but if it makes it harder for someone else to comprehend the logic, you're not doing yourself any real favours.