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

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

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.

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.