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

Есть ли официальное соглашение об именах частных полей в VB.NET? Например, если у меня есть свойство под названием "Foo", я обычно называю частное поле "_Foo". Это, похоже, не одобрено в Offical Guidelines:

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

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

Ответ 1

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

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

Ответ 2

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

Jeff Prosise говорит

В качестве личного предпочтения я обычно префикс private fields с подчеркиванием [в С#]... Это соглашение используется довольно много в .NET Framework, но оно не используется повсеместно.

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

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

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

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

Ответ 3

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

В качестве приватных полей можно указать без ключевого слова "me" (ключевое слово "this" для С#:)

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

Не соответствует CLS
Как правило, теряется, когда VB рисует горизонтальные линии по моей IDE.

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

Ответ 7

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

Public Property Foo As String
Public Property Foo2 As String

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

Ответ 8

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

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

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

Ответ 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

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

Ответ 10

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

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