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

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

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

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

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

лишь подчеркивают.

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

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

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

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

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

потому что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I префиксные переменные-члены с 'm' и параметры (в функции) с 'p'. Поэтому код будет выглядеть так:

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

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

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

один _ используется только как визуальный индикатор. (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 имеет аналогичную возможность с "Me".

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

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

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

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

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

• aSomething: представляет один объект.
• некоторыеManyThings: список объекты.
• isположение, или иSomeThing: для логического состояния.

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

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

Dim _valueName As Integer

Public Property ValueName() As Integer

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

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

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

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

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

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;

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

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

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

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

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

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

Это делает его гораздо легче увидеть, где вы должны пойти, чтобы увидеть оригинал Декларации.

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

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

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

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

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

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

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

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