208

I often see m_ prefix used for variables (m_World,m_Sprites,...) in tutorials, examples and other code mainly related to game development.

Why do people add prefix m_ to variables?

Kara
  • 6,115
  • 16
  • 50
  • 57
kravemir
  • 10,636
  • 17
  • 64
  • 111
  • 5
    See http://en.wikipedia.org/wiki/Hungarian_notation – scable Oct 21 '12 at 14:55
  • 27
    Before mindlessly following suit with hungarian notation, please do some history check on what Hungarian notation really is. Because naming an int iCounter is just pointless. But naming an int xAnnotationPos and yAnnotationPos is reasonable. Use the Semantic version. – AkselK Oct 21 '12 at 19:26
  • Sometimes, imported modules prefix functions and variables so that you are less likely to overwrite them with your own code. It is a way of 'reserving' names for a specific use. – earthmeLon Oct 21 '12 at 21:07
  • Byte56 gave you an answer. I have seen tools which rely on a naming convention such as mVariable to generate additional code, documentation (yes) and automate some redundant tasks on some member variables... – Coyote Oct 22 '12 at 13:06
  • 5
    While "Hungarian" notation is often viciously derided, the particular flavor of it that denotes variable scope does have some real advantages. In addition to identifying the scope of the variable, it prevents name collisions, as when a local, a parm, and a member all have the same intent, and hence the same "semantic" name. This can make the maintenance of large code bases simpler and less error-prone. – Hot Licks Nov 04 '12 at 14:14
  • Duplicate of [Why do variable names often start with the letter 'm'?](http://stackoverflow.com/questions/4237469/why-do-variable-names-often-start-with-the-letter-m) – Dan Dascalescu Dec 29 '15 at 04:53
  • 21
    There are arguments for and against any coding standard, but the question clearly asks what is `m_` for, yet half the responses here are a commentary on why everyone thinks their current favorite is the best. – c z Aug 24 '16 at 17:49

10 Answers10

144

This is typical programming practice for defining variables that are member variables. So when you're using them later, you don't need to see where they're defined to know their scope. This is also great if you already know the scope and you're using something like intelliSense, you can start with m_ and a list of all your member variables are shown. Part of Hungarian notation, see the part about scope in the examples here.

House
  • 3,356
  • 2
  • 25
  • 29
  • 70
    Worst argument for a naming convention ever, you can simply press ctrl+space for intellisense. – orlp Oct 21 '12 at 17:36
  • 19
    @nightcracker eventhough I don't like the prefix, he means to say that when you type m_ and then " CTRL + SPACE " ( unless it's auto) you get a list only containing your members. Not exactly a good reason but it's a plus. – Sidar Oct 21 '12 at 17:49
  • 4
    @nightcracker [Not sure](http://images.wikia.com/en.futurama/images/d/da/Fry_Looking_Squint.jpg) if trying to be funny or just naive. There was a time *before* intellisense and there's still a large number of people that don't use it. I'm **not** saying intellisense is the reason to use this naming convention. I'm saying that's an additional plus if you happen to be using intellisense. Naming conventions are to make code clearer and maintain a standard. – House Oct 21 '12 at 18:10
  • 19
    Worth mentioning that there are lots of other more-or-less standard ways to do the same thing; "m_variable", "m_Variable", "mVariable", "_variable", "_Variable"... which way is 'best' or 'right' (or whether to do it at all) is as contentious and fruitless an argument as 'spaces vs tabs'. :) – Trevor Powell Oct 21 '12 at 22:23
  • 66
    I prefer just using "this->" - kinda makes "m_" redundant and is even better as it's enforced by the compiler (in theory you can pop "m_" on any variable type; can't do that with "this->"). Part of me wishes that C++ would just standardize on making "this->" mandatory. But that's going more into the world of discussion than being an answer. –  Oct 22 '12 at 02:00
  • Well, lets not turn it into a discussion. As Trevor said, it's fruitless. The motivation behind naming conventions or which ones to use are discussions that aren't really on topic for this question (or even the site depending). – House Oct 22 '12 at 05:20
  • @mh01 Consistent use of `this->` is nice, the problem is indeed that you can't really enforce that. I like this convention though. – Laurent Couvidou Oct 22 '12 at 10:06
  • 6
    @LaurentCouvidou, you can't really enforce that devs create member variables prefixed with `m_` either. – SomeWritesReserved Oct 22 '12 at 12:29
  • 3
    @SomeWritesReserved Right. It's somewhat easier to review `m_` prefixes in C++ as all members are more or less declared at the same place in a header. For `this->` on the other hand, I'd say it's more likely to let a few non-prefixed instances slip in method bodies. But yeah, if people decide they don't want to follow this kind of convention, of if they just don't pay attention, you're screwed with both solutions anyway. – Laurent Couvidou Oct 22 '12 at 12:41
  • 1
    +1 for the Ctrl and Space shortcut. I've always used m_, but it looks like I should stop. Using this. followed by Ctrl and Space might be a good way of only showing member variables. It's interesting that in VS2015 if you type this. followed by a member variable, it suggests you simplify your code by removing the this. – DrLazer Oct 08 '15 at 09:19
  • 2
    People should probably keep in mind, this convention existed long before intellisense, and not everyone uses Visual Studio... – House Jun 06 '16 at 15:31
  • Anyway, it's mostly a Microsoft-world, C++ convention style (just like Hungarian, which I don't use anymore in C++ except when maybe referencing or passing vars to C WinAPIs) . I like it for your reasons (intellisense comboboxes and quick to see in raw debuggers such as Windbg). T – Hernán Apr 30 '17 at 03:45
  • 1
    I know this is old... but it certainly seems like a lot of people whom read this don't even understand why @MichaelHouse mentioned using m_ in conjunction with intelliSense. He was simply stating this not to invoke the intelliSense window but instead to group the variables in the list so it isn't congested with non-member variables. I had to comment as at the time of writing this 23 upvoted the first comment and subsequent comments then layered on the same misunderstanding of the point...but I digress.. – eyegropram Dec 01 '17 at 14:30
  • @SomeWritesReserved You can enforce this as a rule with such commonly used tools as Clang. – Kit10 Apr 25 '18 at 17:52
  • One thing I would also add to the answer is that having scope based prefix in your naming convention also helps with preventing bugs. Name hiding is common in languages and often wont issue a warning. This can easily happen where someone adds a function parameter that matches an existing member variable name that is being used elsewhere in the function. Using a prefix short circuits this issue. Const correctness can also help with some versions of this issue. – 0xC0DEFACE Apr 08 '19 at 06:11
  • so many young people here! about 15 years ago, when you did a search for naming conventions, the top hit was a style guide that suggested using m_, sort of like airbnb's js guide now: https://github.com/airbnb/javascript that is the real reason imo. well, it's my reason anyway. – smoore4 Jun 10 '19 at 23:03
  • 1
    take a look at this reasonable answer: https://stackoverflow.com/a/41653441/7827713 Also, IMHO it's easier to look into a function body and know instantly what is a class member and what isn't – Paiusco Sep 15 '20 at 19:45
  • @eyegropram thank you. It was driving me crazy that no one pointed that out. – Ethan Fischer Sep 26 '22 at 05:04
132

In Clean Code: A Handbook of Agile Software Craftsmanship there is an explicit recommendation against the usage of this prefix:

You also don't need to prefix member variables with m_ anymore. Your classes and functions should be small enough that you don't need them.

There is also an example (C# code) of this:

Bad practice:

public class Part
{
    private String m_dsc; // The textual description

    void SetName(string name)
    {
        m_dsc = name;
    }
}

Good practice:

public class Part
{
    private String description;

    void SetDescription(string description)
    {
        this.description = description;
    }
}

We count with language constructs to refer to member variables in the case of explicitly ambiguity (i.e., description member and description parameter): this.

Community
  • 1
  • 1
InfZero
  • 2,944
  • 4
  • 24
  • 36
  • 1
    Another reason is that in java getter/setter are assumed to be getName/setName, so getM_name is bad and you need handle them one by one. – Leon Jan 11 '19 at 05:53
  • 1
    Thanks for writing this. I just wanted to point out that the book you quoted has been out since August 2008 -- and I still find this bad practice in new code today (2019). – alelom Aug 12 '19 at 15:09
  • C# is a very different animal. It allows us to anonymise a lot of code, and we end up with deep life-time scopes. Consider writing a method that contains a local function that actually calls another method that uses a Func etc, and your call stack starts to grow.. Personally I encourage C# developers to use "this.variableName" (as the good example does) when ever accessing a variable, so you know it is an instance variable. (required in TypeScript) Being lower case (first letter) implies private or local, etc. Sometimes people do something following conventions, but don't understand why. – Simon Miller Feb 17 '21 at 06:52
  • 1
    Yes, why use one character when five characters will do? – Oscar Oct 07 '21 at 20:29
  • 2
    Microsoft recommends to use the prefix `_`: _Use camel casing when naming private or internal fields, and prefix them with _ ._ See [this link](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions) ("When editing C# code that follows these naming conventions in an IDE that supports statement completion, typing _ will show all of the object-scoped members.") – jck Mar 08 '22 at 15:04
  • 2
    for c# this is a really terrible advise. it helps a lot to be able to differ between local variables (myVar) and private fields (_myVar). For everything else converning datatypes the IDE helps you which makes hungerian notation obsolete in c#. – Welcor Apr 29 '22 at 19:32
  • I just want to note that the example is very biased. IMO the `m_` prefix is a very small part of the improvements. The main takeaways from the "good practice" is that you should not abbreviate identifiers and use `this` when possible. The `m_` prefix could easily be added to the good practice without negatively affect it IMO. I am biased though. I really do not like the confusion of non-unique identifiers, even if the compiler might be able to sort it out. – Smartskaft2 Jun 18 '22 at 14:15
  • 1
    No, the code I inherited does not have small classes and functions nor was I asked to refactor them. Adding prefixes makes the code easier to digest. – Mike Lowery Sep 09 '22 at 20:29
31

It is common practice in C++. This is because in C++ you can't have same name for the member function and member variable, and getter functions are often named without "get" prefix.

class Person
{
   public:
      std::string name() const;

   private:
      std::string name; // This would lead to a compilation error.
      std::string m_name; // OK.
};

main.cpp:9:19: error: duplicate member 'name'
      std::string name;
                  ^
main.cpp:6:19: note: previous declaration is here
      std::string name() const;
                  ^
1 error generated.

http://coliru.stacked-crooked.com/a/f38e7dbb047687ad

"m_" states for the "member". Prefix "_" is also common.

You shouldn't use it in programming languages that solve this problem by using different conventions/grammar.

mip
  • 8,355
  • 6
  • 53
  • 72
  • +1, although do you have any idea where this common practise of having "gets" with only var name comes from? – Paiusco Sep 15 '20 at 19:48
  • @Paiusco I guess it's Ockham's razor. You don't need to prefix other constructs, such as functions, if there's no conflict. – mip Sep 16 '20 at 16:02
13

The m_ prefix is often used for member variables - I think its main advantage is that it helps create a clear distinction between a public property and the private member variable backing it:

int m_something

public int Something => this.m_something; 

It can help to have a consistent naming convention for backing variables, and the m_ prefix is one way of doing that - one that works in case-insensitive languages.

How useful this is depends on the languages and the tools that you're using. Modern IDEs with strong refactor tools and intellisense have less need for conventions like this, and it's certainly not the only way of doing this, but it's worth being aware of the practice in any case.

AustinWBryan
  • 3,249
  • 3
  • 24
  • 42
Keith
  • 150,284
  • 78
  • 298
  • 434
  • 13
    If you have to write `this.` in your language, then `m_` is really useless. – Ruslan Feb 18 '18 at 15:56
  • @Ruslan the `m_` is to distinguish it from the property it backs - so `this.Something` for the property vs `this.m_something` for the backing member. It's not a convention I prefer myself, but I have mostly seen it used in case insensitive languages (like VB). – Keith Feb 19 '18 at 10:42
  • 2
    Why not, `this.Something` for the property and `this.something` for the backing? Or `this._something` for the backing? `this.m_something` is redundant. I use `_something` so that I don't accidently type it when I go to type `Something`, nothing to do with membershipness or not – AustinWBryan Aug 13 '18 at 02:11
  • @AustinWBryan see my previous comment about case-insensitive languages. Yeah, an `_` prefix on it's own would do the job, but `m_` is the convention. It's not one that I'd use personally, but if you see it in code that was the intent of the author. – Keith Aug 13 '18 at 07:23
11

As stated in the other answers, m_ prefix is used to indicate that a variable is a class member. This is different from Hungarian notation because it doesn't indicate the type of the variable but its context.

I use m_ in C++ but not in some other languages where 'this' or 'self' is compulsory. I don't like to see 'this->' used with C++ because it clutters the code.

Another answer says m_dsc is "bad practice" and 'description;' is "good practice" but this is a red herring because the problem there is the abbreviation.

Another answer says typing this pops up IntelliSense but any good IDE will have a hotkey to pop up IntelliSense for the current class members.

Antoine C.
  • 3,730
  • 5
  • 32
  • 56
Quentin 2
  • 2,156
  • 1
  • 10
  • 8
  • 1
    "but this is a red herring" - Good point. A fair comparison would be `m_description` vs `description`. – Battle Sep 20 '18 at 09:29
10

Lockheed Martin uses a 3-prefix naming scheme which was wonderful to work with, especially when reading others' code.

   Scope          Reference Type(*Case-by-Case)   Type

   member   m     pointer p                       integer n
   argument a     reference r                     short   n
   local    l                                     float   f
                                                  double  f
                                                  boolean b

So...

int A::methodCall(float af_Argument1, int* apn_Arg2)
{
    lpn_Temp = apn_Arg2;
    mpf_Oops = lpn_Temp;  // Here I can see I made a mistake, I should not assign an int* to a float*
}

Take it for what's it worth.

jiveturkey
  • 2,484
  • 1
  • 23
  • 41
  • 3
    Awesome. Thanks for the "example". Where it really comes in handy is when you're editing 200,000 lines of code. – jiveturkey Feb 18 '20 at 20:28
  • 1
    No need to get defensive. I'm honestly trying to help you by showing you that there's a mistake in your answer. Let me be more clear, then: It doesn't matter if you have 5, or 200000 lines of code: The compiler will not let you do an assignment with incompatible pointer types. So the point made in the comment is moot. – Not a real meerkat Feb 18 '20 at 20:35
  • 2
    Didn't mean to come off as defensive. Sorry. – jiveturkey Feb 19 '20 at 14:36
  • 2
    It's a variation of Hungarian notation, which doesn't make sense in modern languages... – mip May 14 '20 at 22:10
  • it is cool but makes code complex. Decoding also takes some time from developer. – mbagher Feb 06 '22 at 01:37
4

As stated in many other responses, m_ is a prefix that denotes member variables. It is/was commonly used in the C++ world and propagated to other languages too, including Java.

In a modern IDE it is completely redundant as the syntax highlighting makes it evident which variables are local and which ones are members. However, by the time syntax highlighting appeared in the late 90s, the convention had been around for many years and was firmly set (at least in the C++ world).

I do not know which tutorials you are referring to, but I will guess that they are using the convention due to one of two factors:

  • They are C++ tutorials, written by people used to the m_ convention, and/or...
  • They write code in plain (monospaced) text, without syntax highlighting, so the m_ convention is useful to make the examples clearer.
sergut
  • 289
  • 2
  • 8
  • One example could be this: https://wiki.qt.io/How_to_Use_QSettings Since the Qt Creator IS using highlighting, the first guess might appear. A bit different might be another convention using _object() for private objects of a class and p_variable if it is a pointer since both is not highligted as I know of and seem to make sense for me to use it. – Ingo Mi Apr 02 '20 at 22:49
4

Others have mentioned that it means a class member. Qt is a popular c++ Framework that uses this notation so alot of C++ GUI tutorial use m_. You can see almost all their examples use m_ for class members. Personally, I use m_ as it is shorter than this-> and feels compact.

2

To complete the current answers and as the question is not language specific, some C-project use the prefix m_ to define global variables that are specific to a file - and g_ for global variables that have a scoped larger than the file they are defined.
In this case global variables defined with prefix m_ should be defined as static.

See EDK2 (a UEFI Open-Source implementation) coding convention for an example of project using this convention.

OlivierM
  • 2,820
  • 24
  • 41
2

One argument that I haven't seen yet is that a prefix such as m_ can be used to prevent name clashing with #define'd macro's.

Regex search for #define [a-z][A-Za-z0-9_]*[^(] in /usr/include/term.h from curses/ncurses.

yyny
  • 1,623
  • 18
  • 20