Я часто вижу m_
префикс , используемый для переменных ( m_World
, m_Sprites
, ...) в учебные пособия, примеры и другого кода , в основном связанные с развитием игры.
Почему люди добавляют префикс m_
к переменным?
hungarian-notation
kravemir
источник
источник
m_
, однако половина ответов здесь - это комментарий о том, почему все считают, что их нынешний фаворит - лучший.Ответы:
Это типичная практика программирования для определения переменных, которые являются переменными-членами. Поэтому, когда вы используете их позже, вам не нужно видеть, где они определены, чтобы знать их область применения. Это также замечательно, если вы уже знаете область действия и используете что-то вроде intelliSense , вы можете начать с того, что отобразится
m_
список всех ваших переменных-членов. Часть венгерской нотации, смотрите часть о сфере действия в примерах здесь .источник
m_
.В Чистом коде: Справочник по мастерству гибкого программного обеспечения есть явная рекомендация против использования этого префикса:
Есть также пример (код C #) этого:
Плохая практика:
Хорошая практика:
Мы рассчитываем с конструкциями языка для обозначения переменных - членов в случае явного неоднозначности ( т.е. ,
description
членов иdescription
параметров):this
.источник
Это обычная практика в C ++. Это связано с тем, что в C ++ нельзя использовать одно и то же имя для функции-члена и переменной-члена, а функции-получатели часто называются без префикса «get».
«m_» означает «член». Префикс "_" также распространен.
Вы не должны использовать его в языках программирования, которые решают эту проблему, используя различные соглашения / грамматику.
источник
m_
Префикс часто используются для переменных - членов - Я думаю , его главное преимущество заключается в том, что она помогает создать четкое различие между общественной собственностью и частной поддержкой переменного члена документа :Это может помочь иметь согласованное соглашение об именах для резервных переменных, и
m_
префикс является одним из способов сделать это - тот, который работает в нечувствительных к регистру языках.Насколько это полезно, зависит от языков и инструментов, которые вы используете. Современные IDE с мощными инструментами рефакторинга и intellisense меньше нуждаются в подобных соглашениях, и это, конечно, не единственный способ сделать это, но в любом случае стоит знать об этой практике.
источник
this.
на вашем языке, тоm_
это действительно бесполезно.m_
должен отличать его от свойства, которое он поддерживает, поэтомуthis.Something
для свойства противthis.m_something
поддерживающего члена. Это не соглашение, которое я предпочитаю сам, но я видел его в основном в нечувствительных к регистру языках (таких как VB).this.Something
для собственности иthis.something
для поддержки? Илиthis._something
для поддержки?this.m_something
избыточно Я использую его_something
так, чтобы случайно не набирать его приSomething
_
префикс сделает эту работу, ноm_
это соглашение. Это не тот, который я бы использовал лично, но если вы видите это в коде, который был намерением автора.Как указано в других ответах,
m_
префикс используется для указания того, что переменная является членом класса. Это отличается от венгерской нотации, потому что она указывает не тип переменной, а ее контекст.Я использую
m_
в C ++, но не в некоторых других языках, где «this» или «self» является обязательным. Мне не нравится, когда 'this->' используется с C ++, потому что он загромождает код.Другой ответ гласит
m_dsc
: «плохая практика» и «описание»; это "хорошая практика", но это красная сельдь, потому что проблема в сокращении.В другом ответе говорится, что при наборе текста
this
появляется IntelliSense, но в любой хорошей IDE есть горячая клавиша для вызова IntelliSense для текущих учеников.источник
m_description
противdescription
.Как указано во многих других ответах, m_ - это префикс, который обозначает переменные-члены. Он / обычно используется в мире C ++ и распространяется и на другие языки, включая Java.
В современной IDE она полностью избыточна, так как подсветка синтаксиса показывает, какие переменные являются локальными, а какие - членами . Однако к тому моменту, когда подсветка синтаксиса появилась в конце 90-х годов, соглашение существовало много лет и было твердо установлено (по крайней мере, в мире C ++).
Я не знаю, на какие учебники вы ссылаетесь, но я предполагаю, что они используют соглашение из-за одного из двух факторов:
источник
Lockheed Martin использует схему именования с 3 префиксами, с которой было приятно работать, особенно при чтении чужого кода.
Так...
Возьми это за то, что оно того стоит.
источник
Чтобы завершить текущие ответы и поскольку вопрос не зависит от языка, некоторые C-проекты используют префикс
m_
для определения глобальных переменных, специфичных для файла, а такжеg_
для глобальных переменных, у которых область действия больше, чем определяемый ими файл.В этом случае глобальные переменные, определенные с префиксом,
m_
должны быть определены какstatic
.См. Соглашение по кодированию EDK2 (реализация с открытым исходным кодом UEFI) для примера проекта, использующего это соглашение.
источник
Один аргумент, который я еще не видел, заключается в том, что префикс, такой как,
m_
может использоваться, чтобы предотвратить конфликт имен с#define
макросом 'd'.Регулярный поиск
#define [a-z][A-Za-z0-9_]*[^(]
в/usr/include/term.h
curses / ncurses.источник