Я часто вижу префикс m_
, используемый для переменных (m_World
, m_Sprites
,...) в учебниках, примерах и других кодах, в основном связанных с развитием игры.
Почему люди добавляют префикс m_
к переменным?
Я часто вижу префикс m_
, используемый для переменных (m_World
, m_Sprites
,...) в учебниках, примерах и других кодах, в основном связанных с развитием игры.
Почему люди добавляют префикс m_
к переменным?
Это типичная практика программирования для определения переменных, являющихся переменными-членами. Поэтому, когда вы используете их позже, вам не нужно видеть, где они определены, чтобы узнать их область действия. Это также отлично, если вы уже знаете область действия, и вы используете что-то вроде intelliSense, вы можете начать с m_
, и будет показан список всех ваших переменных-членов. Часть венгерской нотации см. В разделе в здесь.
В "Чистый код: руководство по гибкому программному мастерству" есть явная рекомендация об использовании этого префикса:
Вам также не нужно префиксные переменные-члены с
m_
больше. Ваши классы и функции должны быть достаточно маленькими, чтобы вы не нуждались в них.
Также есть пример (код С#):
Плохая практика:
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
.
Префикс m_
часто используется для переменных-членов. Я думаю, его основное преимущество заключается в том, что оно помогает создать четкое различие между публичным свойством и переменной частного члена, поддерживающей его:
int m_something
public int Something
{
get { return this.m_something; }
}
Это может помочь иметь согласованное соглашение об именах для резервных переменных, а префикс m_
- один из способов сделать это - тот, который работает на языках, не учитывающих регистр.
Насколько это полезно, зависит от языков и используемых вами инструментов. Современные IDE с сильными инструментами рефакторинга и intellisense меньше нуждаются в подобных соглашениях, и это, конечно, не единственный способ сделать это, но в любом случае стоит осознавать эту практику.
Это обычная практика в С++. Это связано с тем, что в С++ вы не можете иметь одинаковое имя для функции-члена и переменной-члена, а функции 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: error: duplicate member 'name' std::string name; ^ main.cpp:6:19: note: previous declaration is here std::string name() const; ^ 1 error generated.
"m_" состояния для "члена". Префикс "_" также распространен.
Вы не должны использовать его в языках программирования, которые решают эту проблему, используя различные соглашения/грамматику.
Как указано в других ответах, префикс m_
используется, чтобы указать, что переменная является членом класса. Это отличается от венгерской нотации, поскольку она не указывает тип переменной, но ее контекст.
Я использую m_
в С++, но не на некоторых других языках, где 'this' или 'self' является обязательным. Мне не нравится, что "this- > " используется с С++, потому что он загромождает код.
Другой ответ говорит, что m_dsc
- это "плохая практика" и "описание"; это "хорошая практика", но это красная сельдь, потому что проблема заключается в сокращении.
Другой ответ говорит, что ввод текста this
всплывает IntelliSense, но любая хорошая IDE будет иметь горячую клавишу, чтобы всплывать IntelliSense для текущих членов класса.
Как указано во многих других ответах, m_ является префиксом, который обозначает переменные-члены. Он/обычно используется в мире С++ и распространяется на другие языки, включая Java.
В современной среде IDE она полностью избыточна, поскольку подсветка синтаксиса делает очевидным, какие переменные являются локальными, а какие - членами. Однако к тому моменту, когда подсветка синтаксиса появилась в конце 90-х годов, соглашение существовало уже много лет и было твердо установлено (по крайней мере, в мире С++).
Я не знаю, какие учебники вы имеете в виду, но я буду предполагать, что они используют соглашение из-за одного из двух факторов: