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

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

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

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

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

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

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

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

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

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

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

Потому что:

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

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

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

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

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

Update: я не думаю, что C# " это.- префикс выручает "меня."в VB, который все равно увидит" меня.возраст" такой же, как " у меня.Возраст".

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

Почему вообще нотация? И почему бы просто не следовать (для .NET) рекомендациям Microsoft notation, которые полагаются на оболочку имен?

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

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

1. увеличивает человеческое понимание кода без использования IDE. Как и в обзоре кода - который я все еще нахожу наиболее простым для выполнения на бумаге изначально.
2. когда-нибудь писали T-SQL или другие RDBMS хранимые procs? Использование префиксной нотации в именах столбцов базы данных действительно полезно, особенно для тех из нас, кто любит использовать текст редакторы для такого рода вещей.

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

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

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

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

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

Это зависит от того, какой фреймворк я использую! Если я пишу код 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 сама по себе просто выглядит некрасиво.

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

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

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

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

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

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

• помогает членам группы с intellisense.
• легче определить переменные-члены при чтении кода.
• труднее скрыть переменную-член с локальным определением.

_ вместо 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;
  }
}

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

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

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

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

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

Еще один трюк- соглашение об именовании:

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

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

• A Something: представляет один объект.
• Некоторые ManyThings: список объектов.
• isAState или hasSomeThing: for boolean государство.

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

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

Dim _valueName As Integer

Public Property ValueName() As Integer

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

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

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

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

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

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;

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

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

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

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

Ваш пример mul_ направляется к приложению Charles Simonyi венгерская нотация.

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

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

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

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

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

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

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

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

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

В Java одно общее соглашение заключается в предварении переменных-членов "my" andUseCamelCaseForTheRestOfTheVariablename.