Convention de dénomination pour les champs privés VB.NET

StackOverflow https://stackoverflow.com/questions/7642

  •  08-06-2019
  •  | 
  •  

Question

Existe-t-il une convention officielle pour nommer les champs privés dans VB.NET ?Par exemple, si j'ai une propriété appelée « Foo », j'appelle normalement le champ privé « _Foo ».Cela semble être mal vu dans le Directives officielles:

"N'utilisez pas de préfixe pour les noms de champs.Par exemple, n'utilisez pas g_ ou s_ pour distinguer les champs statiques des champs non statiques."

En C#, vous pouvez appeler le champ privé « foo », la propriété « Foo » et faire référence au champ privé comme « this.foo » dans le constructeur.Comme VB.NET n'est pas sensible à la casse, vous ne pouvez pas le faire - des suggestions ?

Était-ce utile?

La solution

J'utilise toujours le préfixe _ en VB pour les champs privés, j'aurai donc _foo comme champ privé et Foo comme propriété.Je fais cela également pour C# et pour presque tous les codes que j'écris.En général, je ne me demanderais pas trop « quelle est la bonne façon de le faire » parce qu'il n'y a pas vraiment de « bonne » manière (bien qu'il existe de très mauvaises façons), mais je me soucierais plutôt de le faire de manière cohérente.

En fin de compte, être cohérent rendra votre code beaucoup plus lisible et maintenable que l'utilisation de n'importe quel ensemble de « bonnes » conventions.

Autres conseils

C'est une préférence personnelle, même si l'idée d'avoir quelques distinction.Même en C#, je ne pense pas qu’il existe une convention largement utilisée.

Jeff Prosise dit

Par préférence personnelle, je préfixe généralement les champs privés avec un trait de soulignement [en C#]...Cette convention est beaucoup utilisée dans le framework .NET mais elle n'est pas utilisée partout.

Du .Directives de conception du framework NET 2e édition page 73.

Jeffrey Richter dit

Je rends tous mes champs privés et je préfixe mes champs d'instance par "m_" et mes champs statiques par "s_" [en C#]

Du .Directives de conception du framework NET 2e édition page 47.Antoine Moore (L'équipe BCL) pense également que l'utilisation de "m_" et "s_" mérite d'être envisagée, page 48.

Les directives officielles ne sont que cela : des directives.Vous pouvez toujours les contourner.Cela étant dit, nous préfixons généralement les champs avec un trait de soulignement dans les deux C# et VB.NET.Cette convention est assez courante (et évidemment, les directives officielles sont ignorées).

Les champs privés peuvent alors être référencés sans le mot clé "me" (le mot clé "this" est pour C# :)

Les directives de conception que vous avez liées indiquent spécifiquement qu'elles s'appliquent uniquement aux champs publics et protégés statiques.Les directives de conception se concentrent principalement sur la conception d'API publiques ;ce que vous faites avec vos membres privés dépend de vous.Je ne suis pas sûr mais je suis relativement sûr que les membres privés ne sont pas pris en compte lorsque le compilateur vérifie la conformité CLS, car seuls les membres publics/protégés viennent y jouer (l'idée est : « Et si quelqu'un qui utilise un langage qui n'autorise pas le personnage _ à essayer d'utiliser votre bibliothèque ?" Si les membres sont privés, la réponse est "Rien, l'utilisateur n'est pas obligé d'utiliser ces membres." mais si les membres sont publics, vous avez des problèmes. )

Cela dit, je vais ajouter à la chambre d'écho et souligner que quoi que vous fassiez, il est important d'être cohérent.Mon employeur exige que les champs privés en C# et VB soient préfixés par _, et comme nous suivons tous cette convention, il est facile d'utiliser du code écrit par quelqu'un d'autre.

Dans VB.NET 4.0, la plupart d'entre vous savent probablement que vous n'avez pas besoin d'écrire explicitement des getters et des setters pour vos déclarations Property comme suit :

Public Property Foo As String
Public Property Foo2 As String

VB crée automatiquement des variables membres privées appelées _Foo et _Foo2.Il semble que Microsoft et l'équipe VS aient adopté la convention _, donc je n'y vois pas de problème.

Je ne pense pas qu'il existe une convention de dénomination officielle, mais j'ai vu que Microsoft utilise m_ dans la DLL Microsoft.VisualBasic (via réflecteur).

J'utilise toujours le préfixe _ en VB pour les champs privés, donc j'aurai _foo comme champ privé et foo comme propriété.Je le fais aussi pour C # et à peu près n'importe quel code que j'écris.Généralement, je ne serais pas trop pris dans "Quelle est la bonne façon de le faire" parce qu'il n'y a pas vraiment de "bonne" manière (bien qu'il y ait de très mauvaises façons) mais plutôt de le faire de manière cohérente.

Je n'ai rien trouvé de mieux que le "_" pour plus de clarté et de cohérence.Les inconvénients incluent :

  • Non conforme CLS
  • A tendance à se perdre lorsque VB trace des lignes horizontales sur mon IDE

Je contourne les lignes en les désactivant dans l'éditeur et j'essaie de ne pas trop penser à la conformité CLS.

Je suis d'accord avec @lomaxx, il est plus important d'être cohérent au sein de l'équipe que d'avoir le droite convention.

Voici néanmoins plusieurs bons endroits pour obtenir des idées et des conseils sur les conventions de codage :

  1. Directives pratiques et bonnes pratiques pour Microsoft Visual Basic et Visual C# Developers de Francesco Balena est un excellent livre qui aborde bon nombre de ces problèmes.
  2. Normes de codage IDesign (pour C# et pour WCF)
  3. Le framework .NET Code source (dans VS2008)

Je préfère utiliser le préfixe de soulignement pour les champs privés.J'utilise la première lettre minuscule pour les paramètres de la méthode.Je suis la directive d'avoir des paramètres camelcase minuscules pour les méthodes, que je considère comme plus importants que la dénomination des champs privés car cela fait partie de l'API de la classe..par exemple.

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

En utilisant ce modèle, vous n'aurez aucun conflit de nom avec le champ privé et votre paramètre constructeur en C# ou VB.NET.

Je suis d'accord que le plus important n'est pas le style que l'on utilise, mais sa cohérence.

Cela dit, le nouveau style MS/.NET pour les champs privés a tendance à être _fooVar (trait de soulignement suivi d'un nom camelCased)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top