Какой префикс вы используете для переменных-членов?

Question

Без сомнения, для понимания кода важно присваивать переменным-членам префикс, чтобы их можно было легко отличить от "обычных" переменных.

Но какой префикс вы используете?

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

В другом проекте мы использовали длинную префиксную форму, которая также включала тип переменной. мул_ например, это префикс a mпеременная типа ember uподписанный lонг.

Теперь дайте мне знать, какой префикс вы используете (и, пожалуйста, объясните причину этого).

Редактировать: Большинство из вас, похоже, пишут код без специальных префиксов для переменных-членов!Зависит ли это от языка?Из моего опыта, Код на C ++ имеет тенденцию использовать символ подчеркивания или m_ в качестве префикса для переменных-членов.А как насчет других языков?

Answer 1

Без сомнения, для понимания кода важно присваивать переменным-членам префикс, чтобы их можно было легко отличить от "обычных" переменных.

Я оспариваю это утверждение.Это совсем не обязательно, если у вас наполовину приличная подсветка синтаксиса.Хорошая IDE может позволить вам написать ваш код на удобочитаемом английском языке и может показать вам тип и область действия символа другими способами.Eclipse делает хорошую работу, выделяя объявления и виды использования символа, когда точка вставки находится на одном из них.

Отредактируй, спасибо, слим:Хороший индикатор синтаксиса, такой как Eclipse, также позволит вам использовать жирный или курсивный текст или вообще изменить шрифты.Например, мне нравится выделять курсивом статичные объекты.

Еще одна правка:Подумайте об этом с такой точки зрения;тип и область действия переменной являются вторичной информацией.Это должно быть доступно и легко выяснить, но не кричать на вас.Если вы используете префиксы типа m_ или такие типы, как LPCSTR, это становится шумом, когда вы просто хотите прочитать первичную информацию – намерение кода.

Третья правка:Это применимо независимо от языка.

Answer 2

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

Это (возможно) не только делает код более читаемым и в некоторой степени "беглым", но и, самое главное, поощряет хорошо структурированные классы и методы.В конце концов, это, таким образом, сводится к совершенно иной проблеме, чем диллема с префиксом или без префикса.

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

Answer 3

Нет.Раньше я использовал подчеркивание, но меня отговорили от этого в проекте, где другим это не понравилось, и я не пропустил это.Приличная среда разработки или приличная память подскажут вам, что является переменной-членом, а что нет.Один из разработчиков нашего проекта настаивает на том, чтобы ставить "this." перед каждой переменной-членом, и мы потакаем ему, когда работаем над областями кода, которые номинально "его".

Answer 4

Только подчеркивание.

В моем случае я использую его, потому что так написано в документе по стандартам кодирования на моем рабочем месте.Однако я не вижу смысла добавлять m_ или какую-то ужасную венгерскую штуку в начало переменной.Минималистичная надпись "только подчеркивание" делает его читабельным.

Answer 5

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

Для c ++ есть еще одна причина предпочесть m_ _ помимо того факта, что _ иногда добавляет префиксы к ключевым словам компилятора.Буква m обозначает переменную-член.Это также дает вам возможность устранять неоднозначность между локальными и другими классами переменных, s_ для статических и g_ для глобальных (но, конечно, не используйте глобальные переменные).

Что касается комментариев о том, что IDE всегда позаботится о вас, действительно ли IDE - единственный способ, которым вы просматриваете свой код?Обладает ли ваш инструмент diff тем же уровнем качества для улучшения синтаксиса, что и ваша IDE?Как насчет вашего инструмента истории изменений системы управления версиями?Вы что, никогда даже не загружаете исходный файл в командную строку?Современные IDE - это фантастически эффективные инструменты, но код должен быть легко читаемым независимо от контекста, в котором вы его читаете.

Answer 6

Я предпочитаю использовать this ключевое слово.Это означает this.data или this->data вместо какого-то зависящего от сообщества именования.

Потому что:

• с современными IDES набор текста this. всплывающие окна intellinsense
• это очевидно для всех, не зная определенного наименования

Кстати, префикс переменных буквами для обозначения их типа устарел в хороших IDE и напоминает мне об этом Статья Джоэла

Answer 7

Мы используем m_, а затем слегка измененную нотацию Симони, точно так же, как говорит Роб в предыдущем ответе.Таким образом, префикс кажется полезным, а m_ не слишком навязчив и по нему легко искать.

Зачем вообще нужны обозначения?И почему бы просто не следовать (для .NET) рекомендациям Microsoft по нотации, которые основаны на кавычках имен?

Сначала последний вопрос:как указывалось, VB.NET безразличен к оболочке.То же самое касается баз данных и (особенно) администраторов баз данных.Когда мне приходится использовать прямые CustomerID и CustomerID (скажем, в C #), у меня болит мозг.Таким образом, casing - это форма обозначения, но не очень эффективная.

Префиксная нотация имеет значение несколькими способами:

1. Повышает понимание человеком кода без использования IDE.Как в code review, который я по-прежнему считаю проще всего изначально выполнить на бумаге.
2. Вы когда-нибудь писали процедуры, сохраненные в T-SQL или других СУБД?Использование префиксных обозначений в именах столбцов базы данных действительно полезно, особенно для тех из нас, кому нравится использовать текстовые редакторы для такого рода работ.

Короче говоря, возможно, использование префикса как формы обозначения полезно, потому что все еще существуют среды разработки, где интеллектуальные IDE недоступны.Представьте, что IDE (программный инструмент) позволяет нам использовать некоторые ярлыки (например, набор текста intellisense), но не включает в себя всю среду разработки.

IDE - это интегрированная среда разработки точно так же, как автомобиль - транспортная сеть:всего лишь одна часть более крупной системы.Я не хочу следовать "автомобильным" правилам, таким как движение по размеченным дорогам, когда иногда быстрее просто пройтись по пустырю.Полагаться на IDE для отслеживания ввода переменных - все равно что использовать автомобильный GPS для передвижения по пустырю.Лучше иметь знания (какими бы неудобными ни были "m_intCustomerID") в переносимой форме, чем бегать обратно к машине при каждом незначительном изменении курса.

Тем не менее, соглашение m_ или соглашение "this" являются удобочитаемыми.Нам нравится m_, потому что он легко поддается поиску и по-прежнему позволяет вводить переменную в соответствии с ним.Согласились с тем, что простое подчеркивание используется слишком многими другими действиями с кодом фреймворка.

Answer 8

Используя C #, я перешел от 'm_'-префикса к просто подчеркивание, поскольку 'm_' равно наследие от C ++.

Официальные рекомендации Microsoft предписывают вам не использовать никаких префиксов и используйте camel-case для частных пользователей и pascal-пример для публичных членов.Проблема в том, что это противоречит другому руководству из того же источника, в котором говорится, что вы должны сделать весь код совместимым со всеми языками, используемыми в .NET.Например, VB.NET не делает разницы между оболочками.

Так что для меня это просто подчеркивание.Это также упрощает доступ через IntelliSense, и внешний код, вызывающий только общедоступные элементы, не должен видеть визуально беспорядочные подчеркивания.

Обновить:Я не думаю, что C# "это".-префикс выручает "Me." в VB, который по-прежнему будет видеть "Me.age" так же, как "Me.Age".

Answer 9

Это зависит от того, какой фреймворк я использую!Если я пишу код MFC, то я использую m_ и венгерская нотация.Для других вещей (которые, как правило, STL / Boost) я добавляю суффикс подчеркивания ко всем переменным-членам и не утруждаю себя венгерской нотацией.

Класс MFC

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 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, просто выглядит уродливо.

Answer 10

Я префиксирую переменные-члены буквой "m", а параметры (в функции) - буквой "p".Таким образом, код будет выглядеть следующим образом:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

Я обнаружил, что это быстро сообщает вам основную область действия любой переменной - если нет префикса, то это локальная.Кроме того, при чтении функции вам не нужно думать о том, что передается, а что является просто локальной переменной.

Answer 11

Это действительно зависит от языка.Я разбираюсь в C ++, и ставить перед всем символ подчеркивания немного сложно.Язык резервирует материал, начинающийся с подчеркивания, для реализации в некоторых случаях (в зависимости от области применения).Существует также специальный режим для двойного подчеркивания или подчеркивания, следующего за заглавной буквой.Поэтому я предлагаю просто избежать этого беспорядка и просто выбрать какой-нибудь другой префикс."м" - это нормально, ИМО."м_" - это немного чересчур, но тоже не страшно.На самом деле это дело вкуса.

Но будьте осторожны с этими _лидирующими оценками.Вы будете удивлены, узнав, сколько внутренних компонентов компилятора и библиотеки названы именно так, и, безусловно, есть место для случайностей и путаницы, если вы не будете предельно осторожны.Просто скажи "нет".

Answer 12

Большую часть времени я использую python.Python требует, чтобы вы использовали self .foo для доступа к атрибуту foo экземпляра текущего класса.Таким образом, решается проблема путаницы локальных переменных, параметров и атрибутов экземпляра, с которым вы работаете.
В целом, мне нравится такой подход, хотя я и не люблю, когда меня заставляют это делать.Таким образом, мой идеальный способ сделать это - не делать этого и использовать некоторую форму доступа к атрибуту this или self для извлечения переменных-членов.Таким образом, мне не нужно загромождать имена метаданными.

Answer 13

Если язык поддерживает это или Я ключевое слово, затем не используйте префикс и вместо него используйте указанное ключевое слово.

Answer 14

еще один трюк заключается в соглашение об именовании:

Все переменные-члены именуются как обычно, без какого-либо префикса (или 'this.' - это обычно делается в проекте).

Но их будет легко отличить от локальной переменной, потому что в моем проекте эти локальные переменные всегда именуются:

• aЧто - то:представляет собой один объект.
• некоторыеМногое другое:список объектов.
• являетсяСостояние или имеетЧто - то:для логического состояния.

Любая переменная, которая не начинается на "a", "some" или "is / имеет", является переменной-членом.

Answer 15

Поскольку VB.NET не чувствителен к регистру, я добавляю к своим переменным-членам символ подчеркивания, а к остальной части имени - верблюжий регистр.Я пишу названия объектов с заглавной буквы.

Dim _valueName As Integer

Public Property ValueName() As Integer

Answer 16

Я принадлежу к тем людям, которые не используют префиксы.

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

Это сверх того, что вы можете получить из контекста переменных и соглашений об именовании (таких как lowerCamelCase для локальных переменных и закрытых полей, UpperCamelCase для свойств и методов и т.д.) И таких вещей, как "hasXXXX" и "isXX" для логических значений.

Я не использовал префиксы в течение многих лет, но раньше я был "этим". монстр префиксов, но я отказался от этого, если в этом нет крайней необходимости (спасибо, Resharper).

Answer 17

Я чудак, и я добавляю к переменным-членам инициалы из имени класса (которое записано в виде верблюда).

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;

Answer 18

Один - единственный _ используется только в качестве визуального индикатора.(C#)

• помогает объединять участников в группы с помощью intellisense.
• легче определить переменные-члены при чтении кода.
• сложнее скрыть переменную-член с локальным определением.

Answer 19

_ вместо того, чтобы 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;
  }
}

Я нахожу первый пример короче и понятнее.

Answer 20

Это в некотором роде зависит от того, на каком языке вы работаете.

В C # вы можете ссылаться на любой элемент, используя префикс "this", например'this.val', что означает, что никаких префиксов не требуется.VB обладает аналогичной возможностью с 'Me'.

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

Обратите внимание, что одним из преимуществ использования встроенной нотации является то, что вы также можете использовать ее при доступе к свойствам и методам класса без ущерба для ваших соглашений об именовании для них (что особенно важно при доступе к непубличным членам).Основная причина использования любого вида индикатора в качестве флага заключается в том, что вы вызываете возможные побочные эффекты в классе, поэтому рекомендуется использовать его при использовании других членов, независимо от того, являются ли они полем / свойством / методом / и т.д.

Answer 21

Я использую верблюжий регистр и подчеркивание, как и многие здесь.Я использую подчеркивание, потому что работаю с C # и привык избегать ключевого слова "this" в своих конструкторах.Я использую варианты с использованием метода case, поэтому подчеркивание напоминает мне, с какой областью я работаю в данный момент.В противном случае я не думаю, что это имеет значение до тех пор, пока вы не пытаетесь добавить ненужную информацию, которая уже очевидна в коде.

Answer 22

Раньше я использовал m_ perfix в C ++, но в C # я предпочитаю просто использовать camel case для поля и pascal case для его свойства.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Answer 23

Мне нравится m_, но до тех пор, пока в коде используется условная база, меня это устраивает.

Answer 24

Ваш пример mul_ приближается к венгерской нотации приложений Чарльза Симони.

Я предпочитаю, чтобы все было просто, и именно поэтому мне нравится использовать m_ в качестве префикса.

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

Answer 25

Я обычно использую m_ в C ++, но был бы не прочь оставить его в Java или C #.И это зависит от стандарта кодирования.Для устаревшего кода, который содержит сочетание символов подчеркивания и m_, я бы реорганизовал код в соответствии с одним стандартом (при разумном размере кода)

Answer 26

Я использую @.

:D j / k - но if в некотором роде зависит от языка.Если у него есть получатели / установщики, я обычно ставлю _ перед закрытой переменной-членом, и получатель / установщик будет иметь то же имя без _.В противном случае я обычно ими не пользуюсь.

Answer 27

Для моих собственных проектов я использую _ как постфикс (как отметил Мартин Йорк выше, _ поскольку префикс резервируется стандартом C / C ++ для реализаций компилятора), и я при работе над Проекты для Symbian.

Answer 28

В Java одним из распространенных соглашений является предварение переменных-членов "my" и usecamelcasefortherestofthevariablename .

Answer 29

Нет, если в этом нет необходимости, в противном случае подчеркните одинарным символом.Применяется для python.

Answer 30

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

Однако я сомневаюсь, что переменные-члены нуждаются в каких-либо специальных обозначениях.Даже игнорируя справку IDE, не очевидно, почему возникла бы путаница между тем, что является локальной переменной, а что - переменной-членом.