Convenzione di denominazione per i campi privati VB.NET

https://stackoverflow.com/questions/7642

08-06-2019
|

Domanda

Esiste una convenzione ufficiale per la denominazione dei campi privati in VB.NET?Ad esempio, se ho una proprietà chiamata "Foo", normalmente chiamo il campo privato "_Foo".Questo sembra essere disapprovato nel Linee guida ufficiali:

"Non utilizzare un prefisso per i nomi dei campi.Ad esempio, non utilizzare g_ o s_ per distinguere i campi statici da quelli non statici."

In C# è possibile chiamare il campo privato "foo", la proprietà "Foo" e fare riferimento al campo privato come "this.foo" nel costruttore.Poiché VB.NET non fa distinzione tra maiuscole e minuscole, non puoi farlo: qualche suggerimento?

Soluzione

Utilizzo ancora il prefisso _ in VB per i campi privati, quindi avrò _foo come campo privato e Foo come proprietà.Lo faccio anche per C# e praticamente per qualsiasi codice che scrivo.Generalmente non mi lascerei prendere troppo da "qual è il modo giusto per farlo" perché non esiste davvero un modo "giusto" (anche se ci sono alcuni modi pessimi), ma piuttosto mi preoccuperei di farlo in modo coerente.

Alla fine, essere coerenti renderà il tuo codice molto più leggibile e gestibile rispetto all'utilizzo di qualsiasi insieme di convenzioni "giuste".

Altri suggerimenti

È una preferenza personale, anche se c'è un ampio supporto per l'avere Alcuni distinzione.Anche in C# non penso che ci sia una convenzione ampiamente utilizzata.

Jeff Prose dice

Per una questione di preferenze personali, in genere antepongo i campi privati con un carattere di sottolineatura [in C#]...Questa convenzione viene utilizzata molto nel framework .NET, ma non viene utilizzata ovunque.

Dal .NET Linee guida per la progettazione di Framework 2a edizione pagina 73.

Jeffrey Richter dice

Rendo privati tutti i miei campi e antepongo i campi di istanza con "m_" e i campi statici con "s_" [in C#]

Dal .NET Linee guida per la progettazione di Framework 2a edizione pagina 47.Anthony Moore (squadra BCL) ritiene che valga la pena prendere in considerazione anche l'uso di "m_" e "s_", pagina 48.

Le linee guida ufficiali sono proprio questo: linee guida.Puoi sempre aggirarli.Detto questo, di solito prefiggiamo i campi con un carattere di sottolineatura Entrambi C# e VB.NET.Questa convenzione è abbastanza comune (e ovviamente ignorata dalle Linee guida ufficiali).

È quindi possibile fare riferimento ai campi privati senza la parola chiave "me" (la parola chiave "this" è per C# :)

Le linee guida di progettazione che hai collegato indicano specificamente che si applicano solo ai campi statici pubblici e protetti.Le linee guida di progettazione si concentrano principalmente sulla progettazione di API pubbliche;quello che fai con i tuoi membri privati dipende da te.Non ne sono sicuro, ma sono relativamente fiducioso che i membri privati non vengano considerati quando il compilatore verifica la conformità CLS, perché solo i membri pubblici/protetti entrano per giocare lì (l'idea è: "E se qualcuno che usa un linguaggio che? non consente che il carattere _ tenti di utilizzare la tua libreria?" Se i membri sono privati, la risposta è "Niente, l'utente non è obbligato a utilizzare questi membri." ma se i membri sono pubblici sei nei guai. )

Detto questo, aggiungerò qualcosa alla camera dell'eco e sottolineerò che qualunque cosa tu faccia, è importante essere coerenti.Il mio datore di lavoro impone che i campi privati sia in C# che in VB abbiano il prefisso _ e poiché tutti noi seguiamo questa convenzione è facile utilizzare codice scritto da qualcun altro.

In VB.NET 4.0, molti di voi probabilmente sanno che non è necessario scrivere esplicitamente getter e setter per le dichiarazioni di proprietà come segue:

Public Property Foo As String
Public Property Foo2 As String

VB crea automaticamente variabili membro private chiamate _Foo e _Foo2.Sembra che Microsoft e il team VS abbiano adottato la convenzione _, quindi non vedo alcun problema.

Non penso che esista una convenzione di denominazione ufficiale, ma ho visto che Microsoft utilizza m_ nella dll Microsoft.VisualBasic (tramite reflector).

Uso ancora il prefisso _ in VB per campi privati, quindi avrò _Foo come campo privato e foo come proprietà.Lo faccio anche per C# e praticamente qualsiasi codice che scrivo.Generalmente non sarei troppo preso da "qual è il modo giusto per farlo" perché non c'è davvero un modo "giusto" (anche se ci sono alcuni modi pessimi) ma piuttosto preoccuparmi di farlo in modo coerente.

Non ho trovato niente di meglio del "_" per chiarezza e coerenza.I contro includono:

Non conforme a CLS
Tende a perdersi quando VB disegna linee orizzontali sul mio IDE

Aggiro le righe disattivandole nell'editor e cerco di non pensare troppo alla conformità CLS.

Sono d'accordo con @lomaxx, è più importante essere coerenti in tutta la squadra che avere il Giusto convenzione.

Tuttavia, ecco alcuni ottimi posti in cui ottenere idee e indicazioni per le convenzioni di codifica:

Linee guida pratiche e procedure consigliate per Microsoft Visual Basic e Visual C# Developers di Francesco Balena è un ottimo libro che affronta molti di questi temi.
Standard di codifica IDesign (per C# e per WCF)
Il .NET Framework Codice sorgente (nel VS2008)

Preferisco utilizzare il prefisso del carattere di sottolineatura per i campi privati.Utilizzo la prima lettera minuscola per i parametri del metodo.Seguo la linea guida di avere parametri camelcase minuscoli per i metodi, che considero più importante della denominazione dei campi privati poiché fa parte dell'API per la classe..per esempio.

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

Utilizzando questo modello, non si verificheranno conflitti di denominazione con il campo privato e il parametro del costruttore in C# o VB.NET.

Sono d'accordo che la cosa più importante non è lo stile che si usa ma che sia coerente.

Detto questo, il nuovo stile MS/.NET per i campi privati tende ad essere _fooVar (sottolineato seguito da un nome camelCased)

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow

Convenzione di denominazione per i campi privati ​​VB.NET

Convenzione di denominazione per i campi privati VB.NET