Соглашение об именах для частных полей VB.NET

Question

Существует ли официальное соглашение о присвоении имен частным полям в VB.NET? Например, если у меня есть свойство с именем «Foo», я обычно называю приватное поле «_Foo». Это, кажется, осуждается в Официальном руководстве :

"Не используйте префикс для имен полей. Например, не используйте g_ или s_ для различения статических и нестатических полей."

В C # вы можете вызывать приватное поле 'foo', свойство 'Foo' и ссылаться на приватное поле как this.foo в конструкторе. Поскольку VB.NET нечувствителен к регистру, вы не можете сделать это - какие-либо предложения?

Answer 1

Я все еще использую префикс _ в VB для личных полей, поэтому в качестве частного поля у меня будет _foo, а в качестве свойства - Foo. Я делаю это и для c #, и практически для любого кода, который я пишу. В общем, я бы не слишком увлекся «как правильно это сделать», потому что на самом деле нет «правильного» пути (хотя есть и очень плохие способы), а скорее был бы заинтересован в том, чтобы делать это последовательно. 1001 *

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

Answer 2

Это личное предпочтение, хотя широко распространено мнение о наличии некоторого различия. Даже в C # я не думаю, что есть одно широко используемое соглашение.

Джефф Просиз говорит

Что касается личных предпочтений, я обычно ставлю префикс частных полей с подчеркиванием [в C #] ... Это соглашение довольно часто используется в среде .NET, но не везде.

Из. Руководства по проектированию NET Framework 2-е издание, стр. 73.

Джеффри Рихтер говорит

Я делаю все свои поля закрытыми и префикс своих полей экземпляра с помощью "m_", а мои статические поля с "s_" [в C #]

Из. Руководства по проектированию NET Framework 2-е издание, стр. 47. Энтони Мур ( BCL team ) также считает целесообразным использование "m_" и "s_", стр. 48.

Answer 3

В VB.NET 4.0 большинство из вас, вероятно, знают, что вам не нужно явно писать методы получения и установки для объявлений свойств следующим образом:

Public Property Foo As String
Public Property Foo2 As String

VB автоматически создает закрытые переменные-члены с именами _Foo и _Foo2. Кажется, что Microsoft и команда VS приняли соглашение _, поэтому я не вижу проблем с ним.

Answer 4

В рекомендациях по проектированию, которые вы указали специально, указано, что они применяются только к статическим открытым и защищенным полям. Руководства по проектированию в основном сосредоточены на разработке общедоступных API; то, что вы делаете со своими личными членами, зависит от вас. Я не уверен, но я относительно уверен, что частные участники не учитываются, когда компилятор проверяет соответствие CLS, потому что только открытые / защищенные члены приходят туда играть (идея в том, что, если кто-то, кто использует язык, который не позволяет символу _ пытаться использовать вашу библиотеку? »Если участники являются личными, ответ« Нет, пользователю не нужно использовать эти члены ». Но если участники являются публичными, у вас проблемы. )

Тем не менее, я собираюсь добавить в эхо-камеру и указать, что что бы вы ни делали, важно быть последовательным. Мой работодатель требует, чтобы закрытые поля в C # и VB начинались с префикса _, и поскольку все мы следуем этому соглашению, легко использовать код, написанный кем-то другим.

Answer 5

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

На частные поля можно ссылаться без ключевого слова "me" (ключевое слово "this" для C #:)

Answer 6

Я все еще использую префикс _ в VB для частные поля, так что я буду иметь _foo как личное поле и Фу как имущество. Я делаю это для C #, а также и практически любой код, который я пишу. Вообще я бы не слишком увлекся в "Как правильно это сделать" потому что на самом деле нет "права" способ (хотя есть некоторые очень плохие способы), а скорее беспокоиться о делать это последовательно.

Я не нашел ничего лучше, чем "_" для ясности и последовательности. Минусы включают в себя:

• Не соответствует CLS
• Склоняется к потере, когда VB рисует горизонтальные линии через мою IDE

Я обхожу строки, отключая их в редакторе, и стараюсь не слишком задумываться о соответствии CLS.

Answer 7

Не думаю, что существует официальное соглашение об именах, но я видел, что Microsoft использует m_ в dll Microsoft.VisualBasic (через отражатель).

Answer 8

Я согласен, что самое важное не в том, какой стиль используется, а в его согласованности.

С учетом вышесказанного, новый стиль MS / .NET для частных полей имеет тенденцию быть _fooVar (подчеркивание, за которым следует имя в формате camelCased)

Answer 9

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

Public Class Class1

    Private _foo As String
    Public Property Foo() As String
        Get
            Return _foo
        End Get
        Set(ByVal value As String)
            _foo = value
        End Set
    End Property

    Public Sub New(ByVal foo As String)
        _foo = foo
    End Sub

End Class

Используя этот шаблон, у вас не будет никаких конфликтов имен с приватным полем и вашим параметром конструктора в C # или VB.NET.

Answer 10

Я согласен с @lomaxx, важнее быть последовательным во всей команде, чем иметь правильное соглашение.

Тем не менее, вот несколько хороших мест, где можно получить идеи и рекомендации для соглашений по кодированию:

1. Практические рекомендации и рекомендации для Microsoft Visual Basic и Visual C # Разработчики - Франческо Балена - отличная книга, в которой рассматриваются многие из этих проблем.
2. Стандарты кодирования IDesign (для C # и для WCF)
3. .NET Framework Исходный код (в VS2008)