Соглашение об именах - подчеркивание в переменных С++ и С#

Общеизвестно видеть имя переменной _var в поле класса. Что означает подчеркивание? Есть ли ссылка для всех этих специальных соглашений об именах?

ОТВЕТЫ

Ответ 1

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

В С++ подчеркивание обычно указывает частную переменную-член.

В С# я обычно вижу, что он используется только при определении базовой переменной частного члена для общедоступного свойства. Другие частные переменные-члены не будут иметь подчеркивания. Это использование в основном ушло в прошлое с появлением автоматических свойств.

До:

private string _name;
public string Name
{
    get { return this._name; }
    set { this._name = value; }
}

После:

public string Name { get; set; }

Ответ 2

Пожалуйста, НЕ используйте UNDERSCORES перед любым именем переменной или именем параметра в С++!!!

Имена, начинающиеся с подчеркивания или двойного подчеркивания, зарезервированы для разработчиков С++. Имена с подчеркиванием зарезервированы для работы библиотеки.

Если вы прочитали стандарт С++ Coding Standard, вы увидите, что на первой странице написано:

"Не переписывайте именования, но используйте согласованное соглашение об именах: существует только два параметра must-dos: a) никогда не использовать" underhanded names ", которые начинаются с подчеркивания или содержат двойной знак подчеркивания; (p2, стандарты кодирования С++, Herb Sutter и Andrei Alexandrescu)

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

Попробуйте собрать простую программу helloWorld.cpp следующим образом:

g++ -E helloWorld.cpp

Вы увидите все, что происходит в фоновом режиме. Вот фрагмент:

   ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
   try
     {
       __streambuf_type* __sb = this->rdbuf();
       if (__sb)
  {
    if (__sb->pubsync() == -1)
      __err |= ios_base::badbit;
    else
      __ret = 0;
  }

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

Также, если вы посмотрите на виртуальные функции-члены, вы увидите, что * _vptr - это указатель, созданный для виртуальной таблицы, который автоматически создается, когда вы используете одну или несколько виртуальных функций-членов в вашем классе! Но эта другая история...

Если вы используете подчеркивания, вы можете столкнуться с проблемами конфликтов, и у вас НЕ ИМЕЕТСЯ ИДЕЯ, что его вызывает, пока не станет слишком поздно.

Ответ 3

На самом деле соглашение _var происходит от VB, а не С# или С++ (m_,... это другое дело).

Это привело к тому, чтобы преодолеть нечувствительность к случаю VB при объявлении существ

например, такой код невозможен в VB, поскольку он рассматривает user и user как один и тот же идентификатор

Private user As String

Public Property User As String
  Get
    Return user
  End Get
  Set(ByVal Value As String)
    user = value
  End Set
End Property

Чтобы преодолеть это, некоторые использовали соглашение, чтобы добавить '_' в личное поле, чтобы это выглядело как

Private _user As String

Public Property User As String
  Get
    Return _user
  End Get
  Set(ByVal Value As String)
    _user = value
  End Set
End Property

Поскольку многие соглашения предназначены для .Net и сохраняют некоторую однородность между С# и VB.NET, они используют один и тот же.

Я нашел ссылку на то, что я говорил: http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

Чехол для верблюда с ведущим подчеркиванием. В VB.NET, всегда указывайте "Защищенный" или "Private", не используйте "Dim". Использование "m_" обескуражен, так как использование имя переменной, которое отличается от собственность только в случае, особенно с защищенные переменные, поскольку это нарушает и сделает вашу жизнь боль, если вы программируете на VB.NET, так как вы должны были бы назвать ваших членов что-то отличное от свойства accessor/mutator. Из всех пункты здесь, главный символ подчеркивания на самом деле является единственным спорным. Я лично предпочитаю это прямо менее верный случай верблюда для моего частные переменные, чтобы у меня не было присвоить имена переменных "this". отличать от параметров в конструкторов или где-либо еще, где я вероятно, будет иметь место именование. С учетом нечувствительности к регистру VB.NET это еще важнее свойства доступа обычно будут иметь то же имя, что и ваш частный член переменные, за исключением подчеркивания. Что касается m_, то это действительно просто об эстетике. Я (и многие другие) найти m_ уродливый, так как выглядит является отверстием в имени переменной. Это почти оскорбительным. Я использовал его в VB6 все время, но это было только потому что переменные не могут иметь ведущий символ подчеркивания. Я не мог быть счастливее видеть, как это уходит. Microsoft рекомендует против m_ (и прямо _), хотя они оба в их коде. Кроме того, префикс прямо "м". Конечно, поскольку они кодируются в основном на С#, они могут имеют закрытых членов, которые отличаются только в случае от свойств. Люди VB должны сделать что-то еще. Скорее, чем попробуйте и придумайте языковые специальные случаи, я рекомендую подчеркнуть все языки, которые его поддержат. Если Я хочу, чтобы мой класс был полностью CLS-совместимый, я мог бы оставить префикс для любого защищенного члена С# переменные. На практике, однако, я никогда не волнуйся об этом, поскольку я держу все потенциально защищенные переменные-члены частных и защищенных аксессуаров и мутаторов. Зачем: Вкратце, это соглашение простой (один символ), легко читаемый (ваш глаз не отвлекает других ведущие персонажи) и успешно избегает конфликтов имен с переменных уровня процедуры и Свойства уровня класса class.class.

Ответ 4

Первый комментатор (R Samuel Klatchko) называет: Каковы правила об использовании подчеркивания в идентификаторе С++?, который отвечает на вопрос об подчеркивании на С++. В общем, вы не должны использовать лидирующий символ подчеркивания, поскольку он зарезервирован для исполнителя вашего компилятора. Код, который вы видите с помощью _var, вероятно, либо устаревший код, либо код, написанный кем-то, кто вырос, используя старую систему именования, которая не хмурилась на ведущих символах подчеркивания.

Как утверждают другие ответы, он использовался в С++ для определения переменных-членов класса. Однако это не имеет особого значения для декораторов или синтаксиса. Поэтому, если вы хотите использовать его, он будет скомпилирован.

Я оставлю обсуждение С# другим.

Ответ 5

Вы можете создать свои собственные правила кодирования. Просто напишите четкую документацию для остальной команды.

Использование _field помогает Intelilsense фильтровать все переменные класса, просто набрав _.

Я обычно следую Brad Adams Guidelines, но рекомендует не использовать подчеркивание.

Ответ 6

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

В С++ использование соглашения _var - это плохая форма, потому что существуют правила, регулирующие использование подчеркивания перед идентификатором. _var зарезервирован как глобальный идентификатор, а _Var (подчеркивание + заглавная буква) зарезервирован в любое время. Вот почему в С++ вы увидите людей, использующих соглашение var_.

Ответ 7

Стандарт именования Microsoft для С# говорит, что переменные и параметры должны использовать нижнюю форму корпуса верблюда IE: paramName. Стандарт также требует, чтобы поля соответствовали одной и той же форме, но это может привести к нечеткому коду, поэтому многие команды требуют префикса подчеркивания для улучшения ясности IE: _fieldName.

Ответ 8

С С# Microsoft Framework Design Guidelines предлагает не использовать символ подчеркивания для общедоступных участников. Для частных участников, символы подчеркивания в порядке. Фактически, Jeffrey Richter (часто цитируется в руководствах) использует m_ для примера и "s_" для частных статических членов.

Лично я использую только _ для пометки своих личных членов. "m_" и "s_" граничат с венгерской нотацией, которая не только нахмурилась в .NET, но может быть довольно многословной, и я считаю, что классы со многими членами трудно выполнять быструю проверку глаз в алфавитном порядке (представьте, что 10 переменных начинаются с m_).

Ответ 9

Что касается языков C и С++, то нет особого значения для подчеркивания в названии (начале, середине или конце). Это просто действительный символ имени переменной. "Соглашения" исходят из практики кодирования в сообществе кодирования.

Как уже указывалось в приведенных выше примерах, _ в начале может означать частные или защищенные члены класса в С++.

Позвольте мне просто рассказать историю, которая может быть забавной мелочью. В UNIX, если у вас есть основная функция библиотеки C и ядро, где вы хотите выставить функцию ядра для пользовательского пространства, а _ застревает перед заглушкой функции, которая напрямую вызывает функцию ядра, не делая ничего другого. Наиболее известным и знакомым примером этого является exit() vs _exit() в ядрах BSD и SysV: там, exit() делает вещи пользовательского пространства перед вызовом службы выхода ядра, тогда как _exit просто отображается в службу выхода ядра.

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

Теперь что касается _ в именах переменных, например

int _foo;

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

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

Ответ 10

Нет никакого единого соглашения об именах, но я видел это для частных членов.

Ответ 11

Из моего опыта (конечно, ограниченного) подчеркивание укажет, что это частная переменная-член. Как сказал Голлум, это будет зависеть от команды.

Ответ 12

Я использую имена _var для переменных-членов моих классов. Есть две основные причины:

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

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

Ответ 13

Многие люди любят иметь приватные поля с префиксом подчеркивания. Это просто соглашение об именах.

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

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

Ответ 14

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

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

Ответ 15

Существует вполне законная причина использовать его в С#:, если код также должен расширяться с VB.NET. (В противном случае я бы не стал.)

Так как VB.NET нечувствителен к регистру, нет простого способа доступа к защищенному элементу field в этом коде:

public class CSharpClass
{
    protected int field;
    public int Field { get { return field; } }
}

например. это приведет к доступу к получателю, а не к полю:

Public Class VBClass
    Inherits CSharpClass

    Function Test() As Integer
        Return Field
    End Function

End Class

Черт, я даже не могу написать field в нижнем регистре - VS 2010 просто исправляет его.

Чтобы сделать его доступным для производных классов в VB.NET, нужно придумать другое соглашение об именах. Префикс подчеркивания, вероятно, является наименее навязчивым и наиболее "исторически принятым" из них.

Ответ 16

Теперь обозначения с использованием "this", как и в этом. foobarbaz, приемлемы для переменных класса класса С#. Он заменяет старую "m_" или просто "__" нотацию. Это делает код более читаемым, потому что нет никаких сомнений в том, что является ссылкой.

Ответ 17

Это просто означает, что это поле члена в классе.

Ответ 18

Соглашение об именовании, подобное этому, полезно, когда вы читаете код, особенно код, который не является вашим собственным. Сильное соглашение об именах помогает указать, где определен конкретный член, какой член он является и т.д. Большинство команд разработчиков принимают простое соглашение об именах и просто префиксные поля-члены с подчеркиванием (_fieldName). Раньше я использовал следующее соглашение об именах для С# (которое основано на соглашениях Microsoft для кода платформы .NET, который можно увидеть с помощью Reflector):

Поле экземпляра: m_fieldName
Статическое поле: s_fieldName
Открытый/Защищенный/Внутренний член: PascalCasedName()
Частный член: camelCasedName()

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