Open arpit-saxena opened 5 years ago
That is my usual habbit. For eg generally if I want to create a variable for TextEdit, I will name is mTextEdit
https://stackoverflow.com/a/7072899/5585431 Did a bit of digging (Just a google search :stuck_out_tongue:). 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.
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
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.
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.
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
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
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
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 _textEdit1mainac mainac represents the main activity. So that almost same name can easily be given with a different id in a different layout file
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?
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
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
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
Isn't the trailing TextEdit
indicative that it is a layout element?
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
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?
Example: