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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле соглашение _var пришло из VB, а не из C# или C++ (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 и для сохранения некоторого единообразия между C# и VB.NET, они используют одно и то же соглашение.

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

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

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

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

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

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

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

int _foo;

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

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

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

Instance Field: m_fieldName
Static Field: s_fieldName
Public/Protected/Internal Member: PascalCasedName()
Private Member: camelCasedName()

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

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

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

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

В C #, Microsoft Framework Design Guidelines предлагает не использовать символ подчеркивания для общедоступных членов. Для членов private можно использовать подчеркивание. Фактически, Джеффри Рихтер (часто цитируемый в руководящих принципах) использует, например, m_ и «s_» для частных статических членов.

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

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

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

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

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

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