这是定义成员变量的典型编程实践。因此，当您以后使用它们时，不需要看到它们的定义位置就可以知道它们的作用域。如果你已经知道作用域，并且你正在使用智能感知之类的东西，这也很好，你可以从m_开始，然后显示所有成员变量的列表。匈牙利符号的一部分，请看这里例子中关于范围的部分。

这在c++中是很常见的做法。这是因为在c++中，成员函数和成员变量的名称不能相同，而getter函数的名称通常没有“get”前缀。

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:错误:重复成员名称 std:: string名称; ＾ Main.cpp:6:19:注意:之前的声明在这里 Std::字符串名称() ＾ 产生1个错误。 http://coliru.stacked-crooked.com/a/f38e7dbb047687ad

“m_”表示成员。前缀“_”也很常见。

你不应该在通过使用不同的约定/语法来解决这个问题的编程语言中使用它。

在《干净代码:敏捷软件工艺手册》中，明确建议不要使用这个前缀:

你也不再需要给成员变量加上m_前缀了。你的类和函数应该足够小，以至于你不需要它们。

这里还有一个例子(c#代码):

坏的做法:

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

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

良好实践:

public class Part
{
    private String description;

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

在显式歧义(即，描述成员和描述形参)的情况下，我们使用语言构造来引用成员变量:this。

我还没有看到的一个参数是，像m_这样的前缀可以用来防止与#define'd宏的名称冲突。

在/usr/include/term.h查找curses/ncurses中的#define [a-z][A-Za-z0-9_]*[^(]

正如在许多其他响应中所述，m_是一个表示成员变量的前缀。它在c++世界中被广泛使用，并传播到其他语言中，包括Java。

在现代IDE中，这完全是多余的，因为语法高亮显示使得哪些变量是局部变量，哪些变量是成员变量变得很明显。然而，当语法高亮显示在90年代末出现时，这个约定已经存在了很多年，并且被牢固地设定了(至少在c++世界中是这样)。

我不知道你指的是哪个教程，但我猜他们使用惯例是由于以下两个因素之一:

它们是c++教程，由习惯m_约定的人编写，和/或… 他们用纯(等宽)文本编写代码，没有语法高亮显示，因此m_约定有助于使示例更清晰。

洛克希德·马丁公司使用了一个3前缀命名方案，这是非常棒的工作，特别是在阅读别人的代码时。

   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

所以…

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*
}

为了它的价值而接受它。