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

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

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

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

11.08.2008 09:41:11
Эти официальные рекомендации предназначены для разработки библиотек классов и применяются только к открытым элементам, а не к частным.
MarkJ 10.06.2010 12:11:31
10 ОТВЕТОВ
РЕШЕНИЕ

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

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

21
11.08.2008 09:45:27

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

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

3
11.08.2008 09:46:46

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

2
11.08.2008 09:48:17

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

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

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

Я предпочитаю использовать префикс подчеркивания для частных полей. Я использую строчную первую букву для параметров метода. Я придерживаюсь принципа наличия в методах параметров в нижнем регистре для верблюдов, которые я считаю более важными, чем присвоение имен частным полям, поскольку они являются частью 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.

0
11.08.2008 19:00:39

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

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

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

2
12.08.2008 15:57:52
Соответствие CLS не заботит имена частных полей.
Jonathan Allen 9.09.2008 08:35:26

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

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

3
28.08.2008 18:36:15

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

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

0
5.09.2008 18:11:53

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

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

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

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

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

Я делаю все свои поля закрытыми, а мои поля экземпляра добавляются с помощью «m_», а мои статические поля - с «s_» [в C #]

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

7
10.06.2010 12:10:12

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

Public Property Foo As String
Public Property Foo2 As String

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

3
29.08.2011 20:55:31