Why do most fields (class members) in Android tutorial start with `m`?

Question

I know about camel case rules, but I'm confused with this m rule. What does it stand for? I'm a PHP developer. "We" use first letters of variables as indication of type, like 'b' for boolean, 'i' for integer and so on.

Is 'm' a Java thing? Does it stand for mobile? mixed?

Exceptive

that prefix does nothing but to mess up the readability ... – Gusset

indicating type as a prefix is bad and called Hungarian notation see thc.org/root/phun/unmaintain.html and kernel.org/doc/Documentation/CodingStyle – Heptachord

because they didn't have much knowledge of the java code style to begin with – Azimuth

@Exceptive i'm confused, in the android code style guide it says public fields are not supposed to be preceded with that. Aren't public, non static-field, also member fields? – Heribertoheringer

In my opinion, if you are having trouble differentiating local variables from member variables, you have much larger problems than conforming to a code convention. Here's the convention I use (sometimes): Long Life, Long Name. Short Life, Short Name. Haven't been confused so far. – Connett

if you are having trouble differentiating local variables from member variables you have a completly different problem. – Awhile

A real stupid prefix. Use your IDE to generate setters/getters and you end up with getmName() and setmName()! Also tools like Lombok for generation setters, getters, contructors etc will generate the m prefix. In my optionion the m prefix does not add value and should be removed from the naming convention. – Auric

@Auric believe me Android IDE enough smart to make normal getters/setters for such variables and more.. So only you comment is "stupid" here. Did you even try? – Novanovaculite

@Novanovaculite Sorry, only tested with IntelliJ/Android Studio and IntelliJ generates setters and getters like getmVariable() and setmVariable(). Did you test it yourselves or are you using another editor? – Auric

@Auric I use Android Studio (the only official IDE for android developing), did you configure next - Settings/Editor/Code Style/Java/Code Generation? postimg.org/image/coxz23utn. IntelliJ should also have it – Novanovaculite

@Auric also here https://mcmap.net/q/79968/-why-do-most-fields-class-members-in-android-tutorial-start-with-m – Novanovaculite

Answer 1

This notation comes from AOSP (Android Open Source Project) Code Style Guidelines for Contributors:

Follow Field Naming Conventions

• Non-public, non-static field names start with m.
• Static field names start with s.
• Other fields start with a lower case letter.
• Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.

Note that the linked style guide is for code to be contributed to the Android Open Source Project.

It is not a style guide for the code of individual Android apps.

Derte

Interesting.. the Google Java Code Style actually contradicts the AOSP Code Style regarding this. – Canzone

I think in these times it's nonsense, especially to do it in your app! "Your classes and functions should be small enough that you don’t need them. And you should be using an editing environment that highlights or colorizes members to make them distinct. Besides, people quickly learn to ignore the prefix (or suffix) to see the meaningful part of the name. The more we read the code, the less we see the prefixes. Eventually the prefixes become unseen clutter and a marker of older code." - Robert Martin in Clean Code – Avarice

Contradicts Google's Java Style Guide - "Non-constant field names (static or otherwise) are written in lowerCamelCase. ... For example, computedValues..." – Tuscan

Please add your comment to this petition to remove the rule code.google.com/p/android/issues/detail?id=226814 – Philosopher

Answer 2

A lot of coding guide lines use m for 'members' of a class. So when you're programming you can see the difference between local and member variables.

Crespi

All modern IDEs differentiate locals and members by color/font, which is IMHO way more readable than m prefix. – Cestus

Please add your comment to this petition to remove the rule code.google.com/p/android/issues/detail?id=226814 – Philosopher

@DzmitryLazerka in most code review tools u do not have this level of highlighting. So it does make sens in a big open source project. – Rahman

@DzmitryLazerka what about reading code in notepad or github and so on? – Novanovaculite

I'd say that doing Java development in notepad is extremely inconvenient, and one should not do that on daily job, they just lose on performance for no reason. I can imagine rare cases when an IDE is unavailable, but why should we optimize for those rare cases? Github is not a development environment either, and I feel like general language guidelines should not depend on one commercial code review tool that has little to do with Java/Android. If they want it, they can implement coloring on their side, but so far it seems like it's not really that important for their users. – Cestus

A lot of coding guies for C and C++ recommend this. It is 'almost' necessary in C++ if you write your constructors properly. Never seen such a thing for Java, where it is unnecessary. – Prettypretty

public foo(String value) { mValue = value; } vs public foo(String value) { this.value = value; } m is less typing :-) – Bifilar

@DzmitryLazerka But then you have to memorize what each color/font means, which may not even be consistent across IDEs. Using unique class variable names also tends to eliminate variable hiding and the use of "this." – Veracity

Answer 3

What is m prefix?

m stands for member variable or data member. Use m prefix for non-public and non-static fields.

When to Use?

private String mCityName;
private float mTemperature;

When not to Use?

public static int mFirstNumber;
public static final String mDATABASE_NAME;

What I do?

Personally, I don't use it. It makes the code more complicated and chaos the readability. If you are still using Notepad for coding I have no words, but modern IDEs are capable of highlighting and coloring member and local variables or anything else.

Conclusion

Use? "Yes" or "No" is your personal choice.

Cloots

you can also use it for public static int, but use s instead of m: public static int sFirstNumber;, see https://mcmap.net/q/79968/-why-do-most-fields-class-members-in-android-tutorial-start-with-m – Novanovaculite

Answer 4

If it's member variables in classes, the 'm' means 'member'. Many Java programmers do that, although with modern IDEs it's not needed since you have highlighting, mouse over tooltips, etc.

Grazynagreabe

I would argue that even with a modern IDE it's nice to prefix members with m or m_ for the purpose of bringing up all member variables for a class in the same place when using code completion. This means that when you're working in a class you can just hit m_ + ctrl space to get a list of all members. – Bewray

Agreed, I usually also prefix members with 'm' in Java. I added that last sentence to show that this is nothing all Java programmers agree on. Sun's coding style for instance doesn't include the 'm' prefix. – Grazynagreabe

Nailer, you could achieve the same by using this. + ctrl space :) – Conga

Also, if you print out the code listing, such is helpful - you don't have the tooltips to help you out there (yes, I like to print out code and read them in an easy chair or even in bed at times). – Myogenic

@Grazynagreabe i'm confused, in the android code style guide it says public fields are not supposed to be preceded with that. Aren't public, non static-field, also member fields? – Heribertoheringer

@domenicop I'm not pro m- prefix, however I guess that the idea is to distinguish between the kinds of attributes within a class. That being said, I usually don't use public non-static attributes anywhere, except in classes that contain exclusively those attributes and no business logic (records classes). In this case, the m is useless as there is no business logic in the class. Therefore, it's better to remove it for readability outside the class (when you reference these fields). – Misconduct

In my opinion if you can't easily distinguish between fields, parameters and variables without using such prefixes, it means there's something wrong with the code. Most likely the class or the method is just too big. – Carboniferous

Answer 5

If you have problems like

your IDE to generate setters/getters and you end up with getmName() and setmName()

Don't forget to do next (Settings/Editor/Code Style/Java/Code Generation):

Update: we don't use something like this in Kotlin (so it's better to switch to it and don't use prefixes anymore)

Novanovaculite

Answer 6

According to Clean Code book, it's not a clean code.

You don't need to prefix member variables with m. Besides, people quickly learn to ignore the prefix or suffix to see the meaningful part of the name.

Reginiaregiomontanus

Answer 7

I think it is very individual which code conventions is used. I prefer to name my variables with the following prefixes:

• m - Method variables
• c - Class variables
• p - Parameter variables

But I guess that each programmer has their own style.

Kwangju

Considering that most Java devs use IDE's which allows setting different visual styles for class, method, static, and parameter variables, I find it much more useful to have for example static variables/methods underlined, class variables in italic, etc. And of course you could set your own fonts and colors. And it will always work no matter what prefixes you use. But, of course, the magic is all gone when you leave the IDE. – Fraternize

Answer 8

To prove that you definitely shouldn't treat this convention for naming variables in your code, I pass a screenshot from a parent Android Studio hereunder.

Find that variables inside an object a specially sorted to put m-variables lower than your native variables. So by naming them in your code with "m" prefix you hide them in a heap from yourself.

Technicality

Answer 9

As a matter of readability the convention of m for member variables and s for static fields should not be used anymore if you are using a modern IDE like Android Studio. Android Studio can differentiate between those without adding m or s.

Bahuvrihi

Answer 10

The one benefit I found of this code style, is when during an auto-complete of some reference to a variable, I know that I can type "m" to see just the member variables.

Shitty

Answer 11

As was mentioned earlier, it is styled for different variable. But also it is very useful for code-generation. If you press "Alt + Insert" you will get windows for most common code generations properties. If you want to generate "get" method for your variable you will get.

public class Foo{
   private int bar;

   public int getBar(){
       return this.bar;
   }

   public void setBar(int bar){
       this.bar = bar; 
   }

}

But if you declare "m, s" you will get:

public class Foo{
private int mBar;

public int getBar(){
   return mBar;
}

public void setBar(int bar){
   mBar = bar;
}
}

It will be automatically generated and "m" or "s" deleted from your constructor, get, set methods name. After this "get"' and "set" for the field will be generated without "m". Andoroid Fle->Setting->Code Style-> Java->Code Genenretion. And make as on a picture. Maybe it will help. Sorry for my eng. Configure android

Kendre

Answer 12

It seems to have been a personal preference of some early Android/Google engineers to start member variables with 'm' and so they recommended it.

Now this rule is being forced down the throats of developers in companies who are neither AOSP contributors, simply because that page is considered Android Code Style rules. There is little if any benefit in that rule. Google should consider removing it. Otherwise please specify that for Android Apps which of the Code Style Rules are optional.

Please add your comment of support to this petition to remove the rule https://code.google.com/p/android/issues/detail?id=226814

Philosopher

Answer 13

It can also be stated that it stand for "mine", as in the Class/Instance is saying "This variable is mine and no one else can get to it." Different to static which, while it might be available to only the Class it is shared by all instances of that class. Like if you were drawing circles you'd need to know how big the radius of each circle is

    private double mRadius;

but at the same time you want a counter to keep track of all circles, inside of the circle class you could have

    private static int sCircleCount;

and then just have static members to increase and decrease the count of the circles you currently have.

Advertence

Answer 14

The following are the naming conventions,

• Non-public, non-static field names start with m.
• Static field names start with s.
• Other fields start with a lower case letter.
• Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.

Example:

public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}

Bundestag