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?
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?
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.
In Clean Code: A Handbook of Agile Software Craftsmanship there is an explicit recommendation about 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
.
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.
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.
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.
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:
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.
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.