Why are a lot of variables prefixed with 'm'?

[arpit-saxena]

Example:

EditText mBookName;
EditText mAccno;
EditText mIssuedTo;
EditText mDate;

[tmibvishal]

That is my usual habbit.
For eg generally if I want to create a variable for TextEdit, I will name is mTextEdit

[arpit-saxena]

https://stackoverflow.com/a/7072899/5585431
Did a bit of digging (Just a google search 😛).
First off, it is only used, if ever, for members of a class, which is certainly not the use case in the code. To be honest, this convention is confusing, inconsistent and basically not required with modern IDEs.
I'm going to remove all those 'm's to make our code more consistent and make future changes easier.

[tmibvishal]

Bro Chill
I use m to differentiate between things like String, int and object of classes like EditText, TextView, Button to know that the name that has m in begging do represent something from the layout file.
You can notice that everything that has started with m, that object is being linked with some layout object using "findViewById".
And you better not change this otherwise it creates a lot of confusion 😜

Note:- Not everything is a convention and nor you are always required to follow the conventions :p its just in my coding style

[arpit-saxena]

1. I already changed it.
2. You'd have to somewhat change your style for the sake of consistency. I have changed my style of writing commits to present tense so the commits are in a consistent style.
3. If you think it's very important to write m, then define the convention properly and mention the advantages. To me, it seems to have no use.

[tmibvishal]

They are just variables and please reset to the last commit. Its something that I use the most, there is no convention in writing the variables names. There should be something to differentiate between objects that refer to a layout object and a normal int, String, class object that has no connection with the layout
For example:- think that if instead of mDate, I would have named the TextEdit of date as "Date" or "date", obviously in a normal glance I would think that it is a normal Date class object.

[arpit-saxena]

I agree with that. But the "m" doesn't make it any clearer what it is. It doesn't say if it is a String, a TextEdit or some Date widget. My point being, we could use some other indicator but not 'm'. It doesn't provide any useful info.

[tmibvishal]

I agree with that I just don't know why I am using m but then if we are using a single alphabet and any alphabet will not make sense
And yea I think we should add some of the basic structure of program and things are that we are using in the guideline column in the readme file
and m is not specifically for TextEdit. I use it for all the layout objects like mLinearLayout for a LinearLayout object, mTextView for a TextView object etc
and using a different alphabet as a prefix for all these different objects will make things more complicated

[arpit-saxena]

So, here's my suggestion:
If there might be any discrepancy regarding the type of the variable, suffix it with "_" + (a 1/2 letter code)
That code could be TV for TextView, D for Date, ET for EditText
So the variable date would then look like date_TV, date_D, date_ET

[arpit-saxena]

m is not specifically for TextEdit. I use it for all the layout objects like mLinearLayout for a LinearLayout object, mTextView for a TextView object etc

Exactly my point. It isn't doing anything helpful.

using a different alphabet as a prefix for all these different objects will make things more complicated

Maybe initially, yeah. But in my opinion, it would increase readability. See my suggestion

[tmibvishal]

It is doing a lot of helpful things. Try doing frontend you would realize that you need to make a different common naming scheme for all the variables that define some layout object
And using different things for TextEdit and all would be more complicated and of no use.

Other note:- just in case you ask anything
Btw just in case you go to the layout file and check ids for different fields :p they also have a common thing, most of those ids are named like textEdit1_mainac
mainac represents the main activity. So that almost same name can easily be given with a different id in a different layout file

[arpit-saxena]

textEdit1_mainac

This thing I can get by. It gives me some information on reading it. It says this a textEdit on the Main activity.

It is doing a lot of helpful things. Try doing frontend you would realize that you need to make a different common naming scheme for all the variables that define some layout object

I definitely agree with all this.

And using different things for TextEdit and all would be more complicated and of no use.

But not this. Why do you think so? Say, if I read mDate how do I know what it is? What information is the 'm' giving the reader other than confusing them?

[tmibvishal]

Ya I think I should have named everything properly but because of the fact that this is a hackathon project I was working pretty fast and not thinking about the basic stuff
A better name for mDate obviously will be mDateTextEdit
I will make everything more neat with comments when we will start working on this project again

[arpit-saxena]

A better name for mDate obviously will be mDateTextEdit

So, now that we have a common ground, what does m signify here? Isn't it redundant? And isn't date_TE shorter, if not better?

PS: Don't say that you want to capitalise the D of Date

[tmibvishal]

Ya I can name it mDate_TE but better would be to use mDate_TextEdit (more clear and no short form)
its not about capitalizing d
Its just that it represent something from the layout file

[arpit-saxena]

Isn't the trailing TextEdit indicative that it is a layout element?

[tmibvishal]

What if I just say that TextEdit textEdittemp = new TextEdit();
change its text and just don't use that, it doesn't represent anything from layout
Obviously, that's something I would not do. But there are a lot of objects that a layout can have maybe more than 50 by default
and I don't remember everything name and if m is a prefix it just makes it very easy and quick to recognize the object if there are many mixed local variables and variables representing things from the layout
What's the problem with m and why are you so obsessed with m, what will it take to add a m in beginning , its just a single alphabet

[arpit-saxena]

What's the problem with m and why are you so obsessed with m, what will it take to add a m in beginning , its just a single alphabet

Dude, chill. We were just having a discussion. Such conventions, if we are using, should be explicit so that they may provide any one reading the code with the required info.

---

I get what you're trying to say there. But why would you ever create a TextEdit that's not linked with the layout?