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

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

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

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

Ответов (10)

Решение

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

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

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

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

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

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

Public Property Foo As String
Public Property Foo2 As String

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

От . Рекомендации по проектированию .NET Framework, 2-е издание, стр.

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

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

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