Какой префикс вы используете для переменных-членов?
Без сомнения, для понимания кода важно назначить переменным-членам префикс, чтобы их можно было легко отличить от "обычных" переменных.
Но какой префикс вы используете?
Я работал над проектами, в которых мы использовали m_ в качестве префикса, в других проектах мы использовали только подчеркивание (что лично мне не нравится, потому что только подчеркивание недостаточно демонстративно).
В другом проекте мы использовали длинную префиксную форму, которая также включала тип переменной. Например, mul_ - это префикс переменной-переменной типа unsigned l ong.
Теперь дайте мне знать, какой префикс вы используете (и, пожалуйста, укажите причину).
РЕДАКТИРОВАТЬ: Большинство из вас, кажется, кодировать без специальных префиксов для переменных-членов! Это зависит от языка? Исходя из моего опыта, код C++ имеет тенденцию использовать подчеркивание или m_ в качестве префикса для переменных-членов. А как насчет других языков?
33 ответа
Без сомнения, для понимания кода важно назначить переменным-членам префикс, чтобы их можно было легко отличить от "обычных" переменных.
Я оспариваю это утверждение. Это не совсем необходимо, если у вас есть полуприличная подсветка синтаксиса. Хорошая среда разработки может позволить вам написать свой код на удобочитаемом английском языке и может показать вам тип и область действия символа другими способами. Eclipse хорошо выполняет свою работу, выделяя объявления и использует символ, когда точка вставки находится на одном из них.
Редактируем, спасибо, тонко: хорошая подсветка синтаксиса, такая как Eclipse, также позволит вам использовать текст, выделенный жирным шрифтом или курсивом, или вообще менять шрифты. Например, мне нравится курсив для статичных вещей.
Другое редактирование: думайте об этом так; тип и область действия переменной являются вторичной информацией. Это должно быть доступно и легко узнать, но не кричать на вас. Если вы используете префиксы, такие как m_ или типа, как LPCSTR, это становится шумом, когда вы просто хотите прочитать первичную информацию - намерение кода.
Третье редактирование: это относится независимо от языка.
Я вообще не использую префиксы. Если я столкнусь с опасностью смешивания локальных переменных или параметров метода с членами класса, то либо метод, либо класс будет слишком длинным и выиграет от разделения.
Это (возможно) не только делает код более читабельным и несколько "беглым", но, что самое важное, поощряет хорошо структурированные классы и методы. В конце концов, это сводится к совершенно другой проблеме, чем префикс или без префикса dillema.
ОБНОВЛЕНИЕ: ну, вкус и предпочтения меняются, не правда ли... Теперь я использую подчеркивание в качестве префикса для переменных-членов, поскольку это оказалось полезным для распознавания локальных и членских переменных в долгосрочной перспективе. Особенно новым членам команды иногда бывает нелегко, когда их не так легко узнать.
Никто. Раньше я использовал подчеркивание, но об этом говорили в проекте, где другим это не нравилось, и я его не пропустил. Приличная IDE или приличная память скажут вам, что является переменной-членом, а что нет. Один из разработчиков нашего проекта настаивает на том, чтобы поставить "это". перед каждой переменной-членом, и мы шутим над ним, когда работаем над областями кода, которые номинально являются "его".
Подчеркни только.
В моем случае я использую его, потому что так написано в документе о стандартах кодирования на моем рабочем месте. Тем не менее, я не вижу смысла добавлять m_ или какую-то ужасную венгерскую вещь в начале переменной. Минималистский "только подчеркивание" делает его читаемым.
Более важно быть последовательным, чем что-либо, поэтому выберите то, с чем вы и ваши товарищи по команде можете согласиться, и придерживайтесь этого. И если язык, на котором вы кодируете, имеет соглашение, вы должны стараться придерживаться его. Нет ничего более запутанного, чем кодовая база, которая непоследовательно следует правилу префиксов.
Для C++ есть еще одна причина, по которой m_ предпочтительнее, кроме того факта, что _ иногда ставит префиксы перед ключевыми словами компилятора. M обозначает переменную-член. Это также дает вам возможность устранить неоднозначность между локальными и другими классами переменных, s_ для статических и g_ для глобальных (но, конечно, не используйте глобальные).
Что касается комментариев о том, что IDE всегда будет заботиться о вас, действительно ли IDE - единственный способ взглянуть на ваш код? У вашего инструмента сравнения такой же уровень качества подсветки синтаксиса, как и у вашей IDE? А как насчет вашего инструмента управления версиями контроля версий? Вы никогда не переводите исходный файл в командную строку? Современные IDE являются фантастическими инструментами эффективности, но код должен легко читаться независимо от контекста, в котором вы его читаете.
Я предпочитаю использовать this ключевое слово. Это означает this.data или же this->data вместо некоторых зависимых от сообщества имен.
Так как:
- с современными наборами IDE
this.всплывающие окна intellinsense - это очевидно для всех, не зная определенного имени
Кстати, префиксные переменные с буквами для обозначения их типа устарели с хорошими IDE и напоминают мне об этой статье Джоэла
Мы используем m_, а затем немного измененную нотацию Simonyi, как сказал Роб в предыдущем ответе. Таким образом, префикс кажется полезным, и m_ не слишком навязчив и его легко найти.
Почему нотация вообще? И почему бы просто не следовать (для.NET) рекомендациям Microsoft по обозначениям, которые основаны на регистре имен?
Сначала вопрос: как уже отмечалось, VB.NET безразличен к корпусу. Так же как базы данных и (особенно) администраторы баз данных. Когда мне нужно сохранить прямые customerID и CustomerID (скажем, в C#), это причиняет боль моему мозгу. Таким образом, оболочка является формой обозначения, но не очень эффективной.
Префиксная нотация имеет значение несколькими способами:
- Увеличивает понимание человеком кода без использования IDE. Как и в обзоре кода - который я до сих пор считаю самым простым на бумаге.
- Вы когда-нибудь писали T-SQL или другие RDBMS хранимые процессы? Использование префиксной нотации в именах столбцов базы данных ДЕЙСТВИТЕЛЬНО полезно, особенно для тех из нас, кто любит использовать текстовые редакторы для такого рода вещей.
Короче говоря, префикс как форма записи полезен, потому что все еще существуют среды разработки, в которых интеллектуальные IDE недоступны. Представьте, что IDE (программный инструмент) позволяет нам использовать некоторые ярлыки (например, типизацию intellisense), но не включает всю среду разработки.
IDE - это интегрированная среда разработки, точно так же, как автомобиль - это транспортная сеть: только одна часть более крупной системы. Я не хочу следовать соглашению о "машинах", например, оставаться на размеченных дорогах, когда иногда быстрее идти по пустыре. Полагаться на IDE для отслеживания переменной набора текста было бы все равно, что использовать GPS автомобиля, чтобы пройти по свободному участку. Лучше иметь знания (хотя и неудобно иметь m_intCustomerID) в переносной форме, чем возвращаться к машине для каждого небольшого изменения курса.
Тем не менее, условное обозначение m_ или условное обозначение this являются читаемыми. Нам нравится m_, потому что он легко ищется и все еще позволяет типизированной переменной следовать за ним. Согласились, что обычное подчеркивание используется слишком многими другими действиями кода структуры.
Используя C#, я перешел от префикса 'm_' к подчеркиванию, так как 'm_' является наследием C++.
Официальное руководство Microsoft рекомендует вам не использовать префиксы, а использовать верблюжий кейс для закрытых членов и паскаль-кейс для открытых участников. Проблема в том, что это противоречит другому руководству из того же источника, в котором говорится, что вы должны сделать весь код совместимым со всеми языками, используемыми в.NET. Например, VB.NET не делает различий между оболочками.
Так что просто подчеркивание для меня. Это также облегчает доступ через IntelliSense, и внешний код, вызывающий только открытых участников, не должен видеть визуально грязные подчеркивания.
Обновление: я не думаю, что C# "это."- префикс помогает "Я". в VB, который по-прежнему будет видеть "Me.age" так же, как "Me.Age".
Это зависит от того, какой фреймворк я использую! Если я пишу код MFC, я использую нотацию m_ и венгерский язык. Для других вещей (которые обычно бывают STL/Boost) я добавляю суффикс подчеркивания ко всем переменным-членам, и я не беспокоюсь о венгерской нотации.
MFC Class
class CFoo
{
private:
int m_nAge;
CString m_strAddress;
public:
int GetAge() const { return m_nAge; }
void SetAge(int n) { m_nAge = n; }
CString GetAddress() const { return m_strAddress;
void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }
};
STL Class
class foo
{
private:
int age_;
std::string address_;
public:
int age() const { return age_; }
void age(int a) { age_ = a; }
std::string address() const { return address_; }
void address(const std::string& str) { address_ = str; }
};
Теперь это может показаться немного странным - два разных стиля - но это работает для меня, и написание большого количества кода MFC, который не использует тот же стиль, что и сам MFC, выглядит просто уродливо.
Если язык поддерживает ключевое слово this или Me, не используйте префикс и вместо него используйте указанное ключевое слово.
Это действительно зависит от языка. Я парень на C++, и префикс всего с подчеркиванием немного хитрый. Язык резервирует материал, который начинается с подчеркивания для реализации в некоторых случаях (в зависимости от области действия). Существует также специальная обработка двойного подчеркивания или подчеркивания, следующего за заглавной буквой. Поэтому я говорю, просто избегайте этого беспорядка и просто выберите другой префикс. "М" в порядке ИМО. "М_" немного много, но и не страшно. Дело вкуса действительно.
Но не упустите эти _leadingUnderscores. Вы будете удивлены, как много внутренних компонентов компилятора и библиотеки, и определенно есть место для аварий и путаницы, если вы не будете особенно осторожны. Просто сказать нет.
Я добавляю переменные-члены к 'm', а параметры (в функции) к 'p'. Так что код будет выглядеть так:
class SomeClass {
private int mCount;
...
private void SomeFunction(string pVarName) {...}
}
Я обнаружил, что это быстро говорит вам об основной области действия любой переменной - если нет префикса, то это локально. Кроме того, при чтении функции вам не нужно думать о том, что передается и что является просто локальной переменной.
Я извращенец, и я добавляю переменные-члены к инициалам из имени класса (которое занято верблюдом).
TGpHttpRequest = class(TOmniWorker)
strict private
hrHttpClient : THttpCli;
hrPageContents: string;
hrPassword : string;
hrPostData : string;
Большинство людей Delphi просто используют F.
TGpHttpRequest = class(TOmniWorker)
strict private
FHttpClient : THttpCli;
FPageContents: string;
FPassword : string;
FPostData : string;
_ вместо this.
я использую _ тоже вместо this. потому что он короче (на4 символа меньше) и является хорошим индикатором переменных-членов. Кроме того, используя этот префикс, вы можете избежать конфликтов имен. Пример:
public class Person {
private String _name;
public Person(String name) {
_name = name;
}
}
Сравните это с этим:
public class Person {
private String name;
public Person(String name) {
this.name = name;
}
}
Я считаю первый пример короче и понятнее.
Одиночный _ используется только как визуальный индикатор. (С #)
- помогает группировать членов с intellisense.
- легче определить переменные-члены при чтении кода.
- Труднее скрыть переменную-член с локальным определением.
Большую часть времени я использую Python. Python требует, чтобы вы использовали self.foo для доступа к атрибуту foo экземпляра текущего класса. Таким образом, проблема смешения локальных переменных, параметров и атрибутов экземпляра, с которым вы работаете, решена.
В целом, мне нравится такой подход, хотя я не люблю, когда его заставляют это делать. Таким образом, мой идеальный способ сделать это - не делать этого и использовать некоторую форму доступа к атрибутам для этого или себя, чтобы получить переменные-члены. Таким образом, мне не нужно загромождать имена метаданными.
Это зависит от того, на каком языке вы работаете.
В C# вы можете ссылаться на любого члена, используя префикс "this", например "this.val", что означает, что префиксы не нужны. VB имеет аналогичную возможность со мной.
В языках, где есть встроенная нотация для указания доступа к элементу, я не вижу смысла в использовании префикса. В других языках, я думаю, имеет смысл использовать то, что принято для этого языка.
Обратите внимание, что одним из преимуществ использования встроенной нотации является то, что вы также можете использовать ее при доступе к свойствам и методам класса, не ставя под угрозу ваши соглашения об именах для них (что особенно важно при доступе к частным элементам). Основная причина использования любого вида индикатора заключается в том, что в качестве признака вы вызываете возможные побочные эффекты в классе, поэтому рекомендуется использовать его при использовании других членов независимо от того, являются ли они полем / свойством / методом / и т. Д.,
Другой трюк - соглашение об именах:
Все переменные-члены называются как обычно, без префикса (или "this.", Как это обычно делается в проекте)
Но их будет легко отличить от локальной переменной, потому что в моем проекте эти локальные переменные всегда называются:
- Нечто: представляет один объект.
- Some ManyThings: список объектов.
- AState или имеет SomeThing: для логического состояния.
Любая переменная, которая не начинается с "a", "some" или "is/has", является переменной-членом.
Поскольку VB.NET не чувствителен к регистру, я добавляю к моим переменным-членам префикс подчеркивания и регистр верблюда, оставшуюся часть имени. Я пишу названия объектов с большой буквы.
Dim _valueName As Integer
Public Property ValueName() As Integer
Я с людьми, которые не используют префиксы.
В настоящее время интегрированные среды разработки настолько хороши, что легко найти информацию о переменной с помощью раскраски синтаксиса, всплывающих подсказок при наведении мыши и простой навигации к ее определению.
Это помимо того, что вы можете получить из контекста переменных и соглашений об именах (таких как lowerCamelCase для локальных переменных и закрытых полей, UpperCamelCase для свойств и методов и т. Д.) И таких вещей, как "hasXXXX" и "isXX" для логических значений.
Я не использовал префиксы в течение многих лет, но я имел обыкновение быть "этим". префикс монстр, но я ушел от этого, если это абсолютно необходимо (спасибо, Решарпер).
Я использую случай верблюда и подчеркиваю как много здесь. Я использую подчеркивание, потому что я работаю с C#, и я привык избегать ключевого слова this в моих конструкторах. Я использую варианты с верблюжьим футляром, поэтому подчеркивание напоминает мне о том, с чем я работаю в то время. В противном случае я не думаю, что это имеет значение, если вы не пытаетесь добавить ненужную информацию, которая уже очевидна в коде.
Мне нравится m_, но до тех пор, пока в кодовой базе используется соглашение, я крут с этим.
Я использовал m_ perfix в C++, но в C# я предпочитаю использовать только верблюжий регистр для поля и паскальский регистр для его свойства.
private int fooBar;
public int FooBar
{
get { return fooBar; }
set { fooBar = value; }
}
Я склонен использовать m_ в C++, но не прочь оставить его в Java или C#. И это зависит от стандарта кодирования. Для унаследованного кода, который имеет смесь подчеркивания и m_, я бы реорганизовал код в один стандарт (учитывая разумный размер кода)
Я использую @.
: D J / K - но если это зависит от языка. Если в нем есть методы получения / установки, я обычно ставлю _ перед закрытой переменной-членом, и получатель / установщик будет иметь то же имя без _. В противном случае я обычно не использую.
Ваш пример mul_ направлен к венгерской нотации "Приложения" Чарльза Симони.
Я предпочитаю держать вещи простыми, и поэтому мне нравится использовать m_ в качестве префикса.
Делая это, намного легче увидеть, куда вам нужно обратиться, чтобы увидеть оригинальную декларацию.
В Java одно общее соглашение заключается в том, чтобы предвосхищать переменные-члены с помощью "my" и "UseCamelCaseForTheRestOfTheVariableName".
Для своих собственных проектов я использую _ в качестве постфикса (как отмечал Мартин Йорк, _ в качестве префикса резервируется стандартом C/C++ для реализаций компилятора) и i при работе над проектами Symbian.
Я использую только суффикс _ (префикс _ зарезервирован в c/ C++, как многие отмечали выше). Мне это нравится в основном потому, что я ненавижу имена параметров, такие как "aCircle", и мне не нравится выписывать this.circle, за исключением случаев, когда это абсолютно необходимо. (Я делаю это только для переменных-членов открытого доступа, потому что для них я не использую символ подчеркивания).
Без префикса. А для чисто функциональных / основанных на стеке имен переменных нет. Но если я действительно должен использовать побочные эффекты, которые я могу, если я хочу что-то выводить, то я использую p-> где p - внешний указатель на параметры, переданные моей функции.
Я думаю, что использование префикса / префиксов становится глупым.
__EXTERN_GLOBAL_hungariannotationvariabletypeVendorName-my_member_prefix-Category-VariableName
Обдумывая пример mul, моя переменная-член, представляющая собой длинную без знака, представляющую код операции для команды умножения, может быть mulmul.