191 votes

naming convention - trait de soulignement dans C + c++ / C# variables

Il est habituellement de voir un `` nom de variable dans un champ de classe. Que signifie le caractère de soulignement ? Y a-t-il une référence pour tous ces convention de nommage particulière ? Merci.

143voto

jdmichal Points 6283

Le trait de soulignement est simplement une convention; rien de plus. En tant que tel, son utilisation est toujours un peu différente pour chaque personne. Voici comment je les comprends pour les deux langues en question:

En C++, un trait de soulignement indique généralement une variable membre privée.

En C#, j'ai l'habitude de le voir utilisé uniquement lors de la définition du sous-jacent variable membre privée pour une propriété publique. D'autres variables de membre privées n'aurait pas un caractère de soulignement. Cet usage a été, en grande partie à la trappe avec l'avènement de l'automatique propriétés.

Avant:

private string _name;
public string Name
{
    get { return this._name; }
    set { this._name = value; }
}

Après:

public string Name { get; set; }

118voto

Cos Glynos Points 51

S'il vous plaît NE PAS utiliser de SOULIGNEMENT avant tout nom de variable, le nom du paramètre dans le C++!!!

Les noms commençant par un caractère de soulignement ou un trait de soulignement double sont RÉSERVÉS pour le C++ exécutants. Les noms avec un trait de soulignement sont réservés à la bibliothèque pour travailler.

Si vous avez une lecture à la Norme de Codage C++, vous verrez que dans la première page il est dit: "Ne pas overlegislate de nommage, mais ne constante convention de nommage: Il y a seulement deux doit-dos: a) ne jamais utiliser de "sournois noms," ceux qui commencent par un derscore ou qui contiennent un trait de soulignement double;" (p2 , C++ Normes de Codage, Herb Sutter et Andrei Alexandrescu)

Aussi, vous pouvez voir par vous-même pourquoi une telle utilisation de souligne peuvent être désastreuses lors du développement d'un logiciel.

Essayez de compiler un simple helloWorld.cpp programme comme ceci:

g++ -E helloWorld.cpp

Vous verrez tout ce qui se passe en arrière-plan. Voici un extrait:

   ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
   try
     {
       __streambuf_type* __sb = this->rdbuf();
       if (__sb)
  {
    if (__sb->pubsync() == -1)
      __err |= ios_base::badbit;
    else
      __ret = 0;
  }

Vous pouvez voir comment beaucoup de noms de commencer avec un trait de soulignement double!

Aussi, si vous regardez virtuel fonctions de membre, vous verrez que *_vptr est le pointeur généré pour la table virtuelle qui est automatiquement créé lorsque vous utilisez l'un ou plus virtuel fonctions de membre dans votre classe.! Mais c'est une autre histoire...

Si vous utilisez des traits de soulignement, vous pourriez obtenir dans les questions de conflit et vous n'AVEZ AUCUNE IDÉE de ce qui en est la cause, jusqu'à ce qu'il soit trop tard.

52voto

Zied Points 1038

En fait l' _var convention vient de VB, C# ou C++ (m_,... c'est autre chose).

Il en est venu à surmonter le compte de la casse de VB lors de la déclaration de Propriétés

par exemple, le code n'est pas possible en VB, car il considère user et User le même identifiant

Private user As String

Public Property User As String
  Get
    Return user
  End Get
  Set(ByVal Value As String)
    user = value
  End Set
End Property

Donc, pour surmonter cette difficulté, certains ont utilisé une convention d'ajouter des '_' pour le domaine privé de venir comme ça

Private _user As String

Public Property User As String
  Get
    Return _user
  End Get
  Set(ByVal Value As String)
    _user = value
  End Set
End Property

Depuis de nombreux convention .Net et de garder une certaine uniformité entre C# et VB.NET convention, ils sont en utilisant la même.

J'ai trouvé la référence de ce que je disais : http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

Chameau Cas avec le trait de Soulignement. Dans VB.NET, indiquez toujours "Protégé" ou "Privé", ne pas utiliser de "Dim". L'utilisation de "m_" est déconseillé, comme il est d'usage d'un nom de la variable qui diffère de l' la propriété par le seul cas, en particulier avec protégé variables qui viole de la conformité, et à faire de votre vie un la douleur si vous programmez en VB.NET comme vous aurait pour nom de vos membres quelque chose de différent de la accesseur/mutateur propriétés. De tous les les articles ici, le trait de soulignement est vraiment le seul point controversé. Personnellement, je préfère droit trait de soulignement (moins de chameau cas pour mon variables privées, de sorte que je n'ai pas pour qualifier les noms de variables avec "this". pour distinguer à partir des paramètres dans les constructeurs ou ailleurs, là où je aura un nommage de collision. Avec VB.NET l'insensibilité, cette est d'autant plus importante que vos accesseur propriétés ont généralement le même nom que votre membre privé les variables, sauf pour le trait de soulignement. Aussi loin que m_ va, il est vraiment juste au sujet de l'esthétique. Je (et beaucoup d'autres) trouver m_ laid, qu'il semble qu'il y est un trou dans le nom de la variable. C'est presque offensant. J'ai utilisé de l'utiliser dans VB6 tout le temps, mais ce n'était qu' parce que les variables ne pouvait pas avoir d' trait de soulignement. Je ne pouvais pas être heureux de le voir s'en aller. Microsoft recommande à l'encontre de la m_ (et le straight _), même si ils ont fait les deux dans leur code. Aussi, les préfixant avec un droite "m" est à droite. Bien sûr, depuis ils code principalement en C#, ils peuvent ont des membres privés qui ne diffèrent que dans le cas de la propriétés. VB gens avez à faire autre chose. Plutôt que de essayer et venir avec langue-à-langue des cas particuliers, je recommander le trait de soulignement pour toutes les langues qui la prennent en charge. Si Je veux ma classe à être entièrement Conformes CLS, je pourrais laisser tomber le préfixe sur C# membre protégé les variables. Dans la pratique, cependant, j' ne jamais s'inquiéter de ce que je garde tous potentiellement protégé variables membres privé, et de la protection de l'alimentation par des accesseurs et des mutateurs à la place. Pourquoi: En un mot, cette convention est simple (un seul caractère), facile à lire (votre oeil n'est pas distrait par d'autres personnages principaux), et avec succès évite les conflits de noms avec au niveau de la procédure de variables et de au niveau de la classe de propriétés.au niveau de la classe de propriétés.

6voto

bsruth Points 1603

Le premier intervenant (R Samuel Klatchko) référencées: Quelles sont les règles concernant l'utilisation d'un trait de soulignement en C++ d'identification? qui répond à la question sur le trait de soulignement en C++. En général, vous n'êtes pas censé utiliser un trait de soulignement, car il est réservé pour le responsable de l'implémentation de votre compilateur. Le code que vous voyez avec _var est probablement l'héritage de code, ou code écrit par quelqu'un qui a grandi à l'aide de l'ancien système de nommage qui n'a pas froncer les sourcils sur les principaux traits de soulignement.

Comme d'autres réponses de l'état, il sert à être utilisé en C++ pour identifier les variables de membre de classe. Cependant, il n'a pas de signification particulière, autant que les décorateurs ou de la syntaxe va. Donc, si vous voulez l'utiliser, il va compiler.

Je vais laisser le C# de discussion pour les autres.

4voto

Vous pouvez créer vos propres directives de codage. Il suffit d’écrire une documentation claire pour le reste de l’équipe.

À l’aide de field, aide à la Intelilsense pour filtrer toutes les variables de classe, juste en tapant .

J’ai généralement suivre les Directives de Brad Adams, mais conseille de ne pas utiliser le trait de soulignement.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X