blocks|key|209679|text|这是定义作为成员变量的变量的典型编程实践。因此，当您稍后使用它们时，无需查看它们的定义位置即可了解它们的作用域。如果你已经知道作用域并且你正在使用像intelliSense这样的东西，那么这也是很棒的，你可以从m_开始，所有成员变量的列表都会显示出来。匈牙利符号的一部分，请参阅examples+here中关于作用域的部分。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|209680|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Hungarian_notation#Examples^0|2X|2|3V|D|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

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 <code>m_</code> and a list of all your member variables are shown. Part of Hungarian notation, see the part about scope in the <a href="http://en.wikipedia.org/wiki/Hungarian_notation#Examples">examples here</a>.

blocks|key|211630|text|m_前缀经常用于成员变量-我认为它的主要优点是它有助于在公共属性和支持它的私有成员变量之间创建一个清晰的区别：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|211631|int+m_something

public+int+Something+=>+this.m_something;+|code-block|syntax|javascript|211632|它有助于为后备变量提供一致的命名约定，而m_前缀就是这样做的一种方式-一种在不区分大小写的语言中工作的方式。|211633|这有多有用取决于您使用的语言和工具。具有强大重构工具和智能感知的现代IDE不太需要这样的约定，当然这不是实现这一点的唯一方法，但在任何情况下都值得注意这种做法。|211634|entityMap^0|0|2|0|0|K|2|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|X|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|P|$]]

The <code>m_</code> 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:

<pre><code>int m_something

public int Something =&gt; this.m_something; 
</code></pre>

It can help to have a consistent naming convention for backing variables, and the <code>m_</code> 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.

blocks|key|3062577|text|在《敏捷代码:敏捷软件工艺手册》(+Clean+Code:+A+Handbook+of+Agile+Software+Craftsmanship+)中，有一个明确的建议，建议不要使用这个前缀：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3062578|你也不再需要用m_作为成员变量的前缀了。你的类和函数应该足够小，以至于你不需要它们。|CODE|3062579|3062580|还有一个这样的示例(C#代码)：|3062581|糟糕的做法：|3062582|public+class+Part
{
++++private+String+m_dsc;+//+The+textual+description

++++void+SetName(string+name)
++++{
++++++++m_dsc+=+name;
++++}
}|code-block|syntax|javascript|3062583|良好实践：|3062584|public+class+Part
{
++++private+String+description;

++++void+SetDescription(string+description)
++++{
++++++++this.description+=+description;
++++}
}|3062585|在显式不明确的情况下(即description成员和description参数)，我们使用语言构造来引用成员变量：this。|3062586|entityMap^0|I|1I|0|7|2|0|0|0|0|0|0|0|C|B|Q|B|1L|4|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@$9|14|A|15|B|H]]|D|@]|E|$]]|$1|I|3|-4|5|6|7|16|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|17|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|18|8|@]|D|@]|E|$]]|$1|N|3|O|5|P|7|19|8|@]|D|@]|E|$Q|R]]|$1|S|3|T|5|6|7|1A|8|@]|D|@]|E|$]]|$1|U|3|V|5|P|7|1B|8|@]|D|@]|E|$Q|R]]|$1|W|3|X|5|6|7|1C|8|@$9|1D|A|1E|B|H]|$9|1F|A|1G|B|H]|$9|1H|A|1I|B|H]]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]]|Z|$]]

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

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

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

Bad practice:

<pre><code>public class Part
{
 private String m_dsc; // The textual description

 void SetName(string name)
 {
 m_dsc = name;
 }
}
</code></pre>

Good practice:

<pre><code>public class Part
{
 private String description;

 void SetDescription(string description)
 {
 this.description = description;
 }
}
</code></pre>

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

blocks|key|3062623|text|这是C%2B%2B中的常见做法。这是因为在C%2B%2B中，成员函数和成员变量不能有相同的名称，而且getter函数的命名通常没有"get“前缀。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3062624|class+Person
{
+++public:
++++++std::string+name()+const;

+++private:
++++++std::string+name;+//+This+would+lead+to+a+compilation+error.
++++++std::string+m_name;+//+OK.
};|code-block|syntax|javascript|3062625|3062626|3062627|+main.cpp:9:19:错误:重复成员'name‘std::string+name；%5E+main.cpp:6:19:注意:+std::string+name()+const；%5E1生成错误。|blockquote|3062628|3062629|http://coliru.stacked-crooked.com/a/f38e7dbb047687ad|offset|length|3062630|3062631|"m_“表示”成员“。前缀"_“也很常见。|3062632|您不应该在通过使用不同约定/语法来解决此问题的编程语言中使用它。|3062633|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|1G|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|16|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|18|8|@]|9|@$O|19|P|1A|1|1B]]|A|$]]|$1|Q|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1E|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|N]]]]

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.

<pre><code>class Person
{
 public:
 std::string name() const;

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

<hr>

<blockquote>
<pre><code>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.
</code></pre>
 
 <a href="http://coliru.stacked-crooked.com/a/f38e7dbb047687ad" rel="noreferrer">http://coliru.stacked-crooked.com/a/f38e7dbb047687ad</a>
</blockquote>

"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.

blocks|key|207546|text|正如在其他答案中所述，m_前缀用于指示变量是类成员。这与匈牙利表示法不同，因为它不指示变量的类型，而是指示其上下文。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|207547|我在C%2B%2B中使用m_，但在其他一些语言中不使用，因为'this‘或'self’是必须的。我不喜欢在C%2B%2B中使用'this->‘，因为它会使代码变得混乱。|207548|另一个答案是m_dsc是“糟糕的实践”，而“description；”是“良好的实践”，但这是转移注意力的问题，因为这里有缩写。|207549|另一个答案是，输入this会弹出IntelliSense，但任何好的集成开发环境都会有一个热键来弹出当前类成员的IntelliSense。|207550|entityMap^0|B|2|0|8|2|0|6|5|0|9|4|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|M|$]]

As stated in the other answers, <code>m_</code> 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 <code>m_</code> 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 <code>m_dsc</code> 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 <code>this</code> pops up IntelliSense but any good IDE will have a hotkey to pop up IntelliSense for the current class members.

blocks|key|3062681|text|正如在许多其他响应中所述，m_是表示成员变量的前缀。它在C%2B%2B世界中被广泛使用，并被传播到其他语言中，包括Java。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3062682|在现代IDE中，这是完全多余的，因为语法高亮显示清楚了哪些变量是局部变量，哪些变量是成员变量。然而，到90年代末语法突出显示出现时，这个约定已经存在了很多年，并且已经牢牢确立了下来(至少在C%2B%2B世界中是这样)。|3062683|我不知道您指的是哪些教程，但我会猜测他们使用该约定是由于以下两个因素之一：|3062684|3062685|它们是C%2B%2B教程，由习惯于m_约定的人编写，和/或...|unordered-list-item|3062686|它们以纯(等宽)文本编写代码，没有语法突出显示，因此m_约定有助于使示例更清晰。|3062687|3062688|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

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: 

<ul>
<li>They are C++ tutorials, written by people used to the m_ convention, and/or...</li>
<li>They write code in plain (monospaced) text, without syntax highlighting, so the m_ convention is useful to make the examples clearer. </li>
</ul>

blocks|key|209821|text|为了完成当前的答案，由于问题不是特定于语言的，一些C项目使用前缀m_来定义特定于文件的全局变量，并使用前缀g_来定义全局变量，这些全局变量的作用域比定义的文件大。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|209822|在这种情况下，使用前缀m_定义的全局变量应该定义为static。|209823|有关使用此约定的项目示例，请参阅EDK2+(a+UEFI+Open-Source+implementation)+coding+convention。|209824|entityMap|0|LINK|mutability|MUTABLE|url|https://edk2-docs.gitbooks.io/edk-ii-c-coding-standards-specification/content/4_naming_conventions/43_identifiers.html#4332-any-variable-with-file-scope-or-better-shall-be-prefixed-by-an-m-or-g^0|W|2|1H|2|0|B|2|P|6|0|G|1M|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|11|8|@]|D|@$9|12|A|13|1|14]]|E|$]]|$1|J|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

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

See <a href="https://edk2-docs.gitbooks.io/edk-ii-c-coding-standards-specification/content/4_naming_conventions/43_identifiers.html#4332-any-variable-with-file-scope-or-better-shall-be-prefixed-by-an-m-or-g" rel="nofollow noreferrer">EDK2 (a UEFI Open-Source implementation) coding convention</a> for an example of project using this convention.

blocks|key|207583|text|我还没有看到的一个论点是，可以使用像m_这样的前缀来防止与#define'd宏的名称冲突。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|207584|正则表达式在/usr/include/term.h中从curses/ncurses搜索#define+[a-z][A-Za-z0-9_]*[%5E(]。|207585|entityMap^0|I|2|T|7|0|6|J|17|U|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

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

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

blocks|key|3062810|text|Lockheed+Martin使用了一个由3个前缀组成的命名方案，这个方案使用起来很棒，特别是在阅读其他人的代码时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3062811|+++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|code-block|syntax|javascript|3062812|所以..。|3062813|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*
}|3062814|不管它值多少钱，就拿去吧。|3062815|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

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

<pre><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
</code></pre>

So...

<pre><code>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*
}
</code></pre>

Take it for what's it worth.

blocks|key|207623|text|其他人提到，它的意思是一个类成员。Qt是一个流行的c%2B%2B框架，它使用了这种表示法，因此很多C%2B%2B图形用户界面教程都使用m_。您可以看到，几乎所有的示例都对类成员使用m_。就我个人而言，我使用m_是因为它比this->短，而且感觉很紧凑。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|207624|entityMap^0|1N|2|2A|2|2N|2|2U|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

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 <code>m_</code>. You can see almost all their examples use <code>m_</code> for class members. Personally, I use <code>m_</code> as it is shorter than <code>this-&gt;</code> and feels compact.

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

Why do people add prefix <code>m_</code> to variables?

What does `m_` variable prefix mean?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我经常看到m_ 前缀用于变量 (m_World，m_Sprites，...)在教程、示例等代码中主要涉及到游戏开发。为什么人们要在变量中添加前缀m_？

问`m_`变量前缀是什么意思？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问`m_`变量前缀是什么意思？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问`m_`变量前缀是什么意思？
EN