Convenção de nomenclatura para VB.NET campos privados

Question

Há um oficial da convenção de atribuição de nomes de campos particulares em VB.NET?Por exemplo, se eu tenho uma propriedade chamada 'Foo', eu normalmente chamada privada campo '_Foo'.Este parece ser desaprovado no Oficial De Diretrizes:

"Não usar um prefixo para nomes de campo.Por exemplo, não use g_ ou s_ para distinguir estática versus não-estático de campos."

Em C#, você pode ligar para o campo particular 'foo', a propriedade 'Foo', e referem-se ao campo particular como 'isso.foo' no construtor.Como VB.NET é sensível a maiúsculas e minúsculas você não pode fazer isso - alguma sugestão?

Answer 1

Eu ainda uso o _ prefixo no VB para campos particulares, então eu vou ter _foo como o campo particular e Foo como a propriedade.Eu faço isso para c# bem e praticamente qualquer código que eu escrevo.Geralmente eu não iria ficar muito preso "qual é o caminho certo para fazê-lo" porque não há realmente uma forma "correta" (embora há alguns muito maus caminhos), mas, ao invés de estar preocupado com a fazê-lo de forma consistente.

No final do dia, sendo consistente irá tornar seu código mais legível e fácil de manter do que usando qualquer conjunto de "direito" de convenções.

Answer 2

É uma preferência pessoal, apesar de haver um amplo apoio por ter alguns distinção.Mesmo em C# eu não acho que há um amplamente utilizado convenção.

Jeff Prosise diz

Como uma questão de preferência pessoal, eu normalmente prefixo campos privada com um carácter de sublinhado [C#] ...Esta convenção é muito usadas em .NET framework, mas ele não é utilizado por toda parte.

A partir do .NET Framework Diretrizes de Design 2ª Edição, página 73.

Jeffrey Richter diz

Eu faço todos os meus campos privados e eu prefixo meu campos de instância com "m_" e o meu campos estáticos com "s_" [C#]

A partir do .NET Framework Diretrizes de Design 2ª Edição, página 47.Anthony Moore (Equipe BCL) também acha usando "m_" e "s_" é pena consideração, página 48.

Answer 3

Orientações oficiais são apenas isso-diretrizes.Você pode sempre ir em torno deles.O que está sendo dito nós normalmente prefixo campos com um carácter de sublinhado no ambos C# e VB.NET.Esta convenção é muito comum (e, obviamente, as Orientações Oficiais ignorado).

Campos privados, em seguida, pode ser referenciado sem o "eu" palavra-chave ("este" palavra-chave é para C# :)

Answer 4

As diretrizes de design que você vinculada especificamente estado em que eles se aplicam apenas para o público estático e campos protegidos.O projeto diretrizes, principalmente, o foco na concepção de APIs públicas;o que você faz com seus membros privada é até você.Eu não sou positivo, mas eu sou relativamente confiante de que os membros privados não são consideradas quando o compilador verifica CLS conformidade, porque só public/protected membros vêm para jogar lá (a ideia é, "o Que fazer se alguém que usa uma linguagem que não permite o caractere _ tenta usar sua biblioteca?" Se os membros são privadas, a resposta é "Nada", o usuário não precisa usar esses membros." mas, se os membros estão público, você está em apuros.)

O que disse, eu estou indo para adicionar para a câmara de eco e de salientar que o que você faz, o importante é ser consistente.Meu empregador exige que os campos privados em C# e VB são prefixados com _, e porque todos nós seguir essa convenção é fácil utilizar o código escrito por outra pessoa.

Answer 5

No VB.NET 4.0, a maioria de vocês provavelmente sabem que você não precisa explicitamente escrever getters e setters para a sua Propriedade declarações da seguinte forma:

Public Property Foo As String
Public Property Foo2 As String

VB automaticamente cria variáveis de membro privado chamado _Foo e _Foo2.Parece que a Microsoft e a VS equipa adotaram o _ convenção, para que eu não vejo um problema com ele.

Answer 6

Eu não acho que há um oficial de convenção de nomenclatura, mas eu vi que a Microsoft usa m_ na Microsoft.VisualBasic dll (via refletor).

Answer 7

Eu ainda uso o _ prefixo no VB campos particulares, então eu vou ter _foo como o campo particular e Foo como o propriedade.Eu faço isso para c# bem e praticamente qualquer código que eu escrevo.Geralmente eu não iria ficar muito preso em "o que é o caminho certo para fazê-lo". porque não há realmente uma "direita" forma (embora há alguns muito ruim formas), mas, ao invés de estar preocupado com a fazendo isso de forma consistente.

Eu não encontrei nada melhor do que o "_" para esclarecer e consistência.Contras incluem:

• Não compatíveis com CLS
• Tende a se perder quando o VB desenha linhas horizontais em toda a minha IDE

I get around as linhas ligando-los no editor, e tente não pensar demais sobre o CLS conformidade.

Answer 8

Eu concordo com o @lomaxx, é mais importante ser consistente durante toda a equipe que tem o direito convenção.

Ainda assim, aqui estão alguns bons lugares para se obter idéias e orientações para convenções de codificação:

1. Prática de Diretrizes e Práticas recomendadas para o Microsoft Visual Basic e o Visual C# Os desenvolvedores por Francesco Balena é um ótimo livro que trata de muitos destes problemas.
2. IDesign Padrões De Codificação (para C# e para o WCF)
3. A .NET Framework Código-Fonte (no VS2008)

Answer 9

Eu prefiro usar o sublinhado prefixo para campos privados.Eu uso minúsculas primeira letra para os parâmetros do método.Que eu siga a orientação de ter minúsculas camelcase parâmetros para métodos, o que eu considero mais importante do que a atribuição de nomes de campos privados, pois é parte da API para a classe..exemplo:

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

Usando esse padrão, você não terá quaisquer conflitos de nomes com o campo particular e o seu parâmetro de construtor em C# ou VB.NET.

Answer 10

Eu concordo que o mais importante não é o estilo que se usa, mas ele está sendo coerente.

Com o que disse, o novo MS/.NET styling para campos privada tende a ser _fooVar (sublinhado seguido por um camelcase nome)