Что означает префикс переменной m_?

Я часто вижу m_префикс , используемый для переменных ( m_World, m_Sprites, ...) в учебные пособия, примеры и другого кода , в основном связанные с развитием игры.

Почему люди добавляют префикс m_к переменным?

Это типичная практика программирования для определения переменных, которые являются переменными-членами. Поэтому, когда вы используете их позже, вам не нужно видеть, где они определены, чтобы знать их область применения. Это также замечательно, если вы уже знаете область действия и используете что-то вроде intelliSense , вы можете начать с того, что отобразится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;
    }
}

Мы рассчитываем с конструкциями языка для обозначения переменных - членов в случае явного неоднозначности ( т.е. , descriptionчленов и descriptionпараметров): this.

Это обычная практика в C ++. Это связано с тем, что в C ++ нельзя использовать одно и то же имя для функции-члена и переменной-члена, а функции-получатели часто называются без префикса «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: 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_» означает «член». Префикс "_" также распространен.

Вы не должны использовать его в языках программирования, которые решают эту проблему, используя различные соглашения / грамматику.

m_Префикс часто используются для переменных - членов - Я думаю , его главное преимущество заключается в том, что она помогает создать четкое различие между общественной собственностью и частной поддержкой переменного члена документа :

int m_something

public int Something => this.m_something; 

Это может помочь иметь согласованное соглашение об именах для резервных переменных, и m_префикс является одним из способов сделать это - тот, который работает в нечувствительных к регистру языках.

Насколько это полезно, зависит от языков и инструментов, которые вы используете. Современные IDE с мощными инструментами рефакторинга и intellisense меньше нуждаются в подобных соглашениях, и это, конечно, не единственный способ сделать это, но в любом случае стоит знать об этой практике.

Как указано в других ответах, m_префикс используется для указания того, что переменная является членом класса. Это отличается от венгерской нотации, потому что она указывает не тип переменной, а ее контекст.

Я использую m_в C ++, но не в некоторых других языках, где «this» или «self» является обязательным. Мне не нравится, когда 'this->' используется с C ++, потому что он загромождает код.

Другой ответ гласит m_dsc: «плохая практика» и «описание»; это "хорошая практика", но это красная сельдь, потому что проблема в сокращении.

В другом ответе говорится, что при наборе текста thisпоявляется IntelliSense, но в любой хорошей IDE есть горячая клавиша для вызова IntelliSense для текущих учеников.

Как указано во многих других ответах, m_ - это префикс, который обозначает переменные-члены. Он / обычно используется в мире C ++ и распространяется и на другие языки, включая Java.

В современной IDE она полностью избыточна, так как подсветка синтаксиса показывает, какие переменные являются локальными, а какие - членами . Однако к тому моменту, когда подсветка синтаксиса появилась в конце 90-х годов, соглашение существовало много лет и было твердо установлено (по крайней мере, в мире C ++).

Я не знаю, на какие учебники вы ссылаетесь, но я предполагаю, что они используют соглашение из-за одного из двух факторов:

• Это учебники по С ++, написанные людьми, привыкшими к соглашению m_, и / или ...
• Они пишут код в виде простого (моноширинного) текста без подсветки синтаксиса, поэтому соглашение m_ полезно, чтобы сделать примеры понятнее.

Lockheed Martin использует схему именования с 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*
}

Возьми это за то, что оно того стоит.

Чтобы завершить текущие ответы и поскольку вопрос не зависит от языка, некоторые C-проекты используют префикс m_для определения глобальных переменных, специфичных для файла, а также g_для глобальных переменных, у которых область действия больше, чем определяемый ими файл.
В этом случае глобальные переменные, определенные с префиксом, m_ должны быть определены как static.

См. Соглашение по кодированию EDK2 (реализация с открытым исходным кодом UEFI) для примера проекта, использующего это соглашение.

Один аргумент, который я еще не видел, заключается в том, что префикс, такой как, m_может использоваться, чтобы предотвратить конфликт имен с #defineмакросом 'd'.

Регулярный поиск #define [a-z][A-Za-z0-9_]*[^(]в /usr/include/term.hcurses / ncurses.