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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

Поскольку

• В настоящее время IDE набирают this. popups intellinsense
• его очевидный для всех, не зная определенного именования

Претензионные переменные BTW с буквами для обозначения их типа устаревают с хорошими IDE. И помнит меня об этой статье Joel

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

• Увеличивает понимание человеком кода без использования среды IDE. Как и в обзоре кода, который мне по-прежнему легче всего делать на бумаге.
• Вы когда-нибудь пишете T-SQL или другие хранимые процедуры RDBMS? Использование префиксной нотации в именах столбцов базы данных ДЕЙСТВИТЕЛЬНО полезно, особенно для тех из нас, кто любит использовать текстовые редакторы для такого рода материалов.

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

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

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

Ответ 9

Это действительно зависит от языка. Я парень С++, и префикс всего с подчеркиванием немного сложнее. Язык оставляет материал, который начинается с подчеркивания для реализации в некоторых случаях (в зависимости от области действия). Там также особое внимание уделяется двойному подчеркиванию или подчеркиванию, которое следует за большой буквы. Поэтому я говорю, что просто избегайте этого беспорядка и просто выберите другой префикс. 'm' в порядке IMO. "m_" немного, но не ужасно. На самом деле дело вкуса.

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

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

Ответ 15

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

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

Ответ 16

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

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

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

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

Ответ 17

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

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

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

• a Что-то: представляет один объект.
• some ManyThings: список объектов.
• . ASTate или имеет SomeThing: для логического состояния.

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

Ответ 18

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

Dim _valueName As Integer

Public Property ValueName() As Integer

Ответ 19

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

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

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

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

Ответ 20

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

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;

Ответ 21

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

Ответ 22

Я использовал m_ perfix в С++, но в С# я предпочитаю использовать только случай верблюда для поля и паскаля для его свойства.

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

Ответ 23

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

Ответ 24

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

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

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

Ответ 25

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

Ответ 26

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

Ответ 27

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

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

Ответ 28

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

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

Ответ 29

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

Ответ 30

В Java одно общее соглашение состоит в том, чтобы предикать переменные-члены с помощью "my" иUseCamelCaseForTheRestOfTheVariableName.