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

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

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

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

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

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

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

я не нашел, что что-либо лучше, чем "_" для разъясняется и непротиворечивость. Недостатки включают:

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

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

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

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

1. Практические Инструкции и Лучшие практики для Microsoft Visual Basic и Визуального C# Разработчики Francesco Balena являются замечательной книгой, которая решает многие из этих проблем.
2. IDesign Кодирование Стандартов (для C# и для WCF)
3. Платформа.NET Исходный код (в VS2008)

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

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

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

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

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

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

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

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

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

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