Convention de nommage – trait de soulignement dans les variables C ++ et C #

Il est courant de voir un nom de variable _var dans un champ de classe. Que signifie le soulignement? Existe-t-il une référence pour toutes ces conventions de nommage spéciales?

Le soulignement est simplement une convention; rien de plus. En tant que tel, son utilisation est toujours quelque 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 de membre privé.

En C #, je le vois généralement utilisé uniquement lors de la définition de la variable de membre privé sous-jacente pour une propriété publique. Les autres variables de membre privé n’auraient pas de soulignement. Cet usage a largement été abandonné avec l’avènement des propriétés automatiques.

Avant:

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

Après:

 public ssortingng Name { get; set; } 

Merci de ne pas utiliser UNDERSCORES avant un nom de variable ou un nom de paramètre en C ++ !!!

Les noms commençant par un trait de soulignement ou un double trait de soulignement sont réservés aux implémenteurs C ++. Les noms avec un trait de soulignement sont réservés à la bibliothèque.

Si vous avez lu le C ++ Coding Standard, vous verrez que dans la toute première page, il est écrit:

“Ne pas exagérer le nommage, mais utiliser une convention de dénomination cohérente: il n’y a que deux must-dos: a) ne jamais utiliser de” noms sournois “, qui commencent par un trait de soulignement ou qui contiennent un double soulignement;” (p2, normes de codage C ++, Herb Sutter et Andrei Alexandrescu)

En outre, vous pouvez voir par vous-même pourquoi une telle utilisation des traits de soulignement peut être désastreuse lors du développement d’un logiciel.

Essayez de comstackr un simple programme helloWorld.cpp 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 combien de noms commencent par un double soulignement!

En outre, si vous examinez les fonctions des membres virtuels, vous verrez que * _vptr est le pointeur généré pour la table virtuelle qui est automatiquement créée lorsque vous utilisez une ou plusieurs fonctions membres virtuelles dans votre classe! Mais c’est une autre histoire …

Si vous utilisez des caractères soulignés, vous risquez de vous heurter à des problèmes de conflit et vous N’AUREZ AUCUNE IDÉE ce qui en est la cause, jusqu’à ce qu’il soit trop tard.

En fait, la convention _var vient de VB et non de C # ou C ++ (m _, … est une autre chose).

Cela est venu à surmonter l’insensibilité à la casse de VB lors de la déclaration des propriétés

par exemple, un tel code n’est pas possible dans VB car il considère l’ user et l’ User comme le même identifiant

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

Donc, pour surmonter cela, certains ont utilisé une convention pour append «_» au domaine privé pour venir comme ça

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

Comme beaucoup de conventions sont pour .Net et pour garder une certaine uniformité entre les conventions C # et VB.NET, elles utilisent le même.

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

Camel Case avec Leading Underscore. Dans VB.NET, indiquez toujours “Protected” ou “Private”, n’utilisez pas “Dim”. L’utilisation de “m_” est déconseillée, de même que l’utilisation d’un nom de variable différent de la propriété uniquement par cas, en particulier avec les variables protégées car cela viole la conformité et rendra votre vie difficile si vous programmez VB.NET comme vous le souhaitez. devrait nommer vos membres quelque chose de différent des propriétés accesseur / mutateur. De tous les articles ici, le principal soulignement est vraiment le seul controversé. Personnellement, je le préfère aux cas de chameaux sans soulignement pour mes variables privées, de sorte que je n’ai pas à qualifier les noms de variables avec “ceci”. distinguer des parameters dans les constructeurs ou ailleurs où je vais probablement avoir une collision de noms. Avec l’insensibilité à la casse de VB.NET, cela est d’autant plus important que vos propriétés d’accesseur auront généralement le même nom que vos variables de membre privé, à l’exception du trait de soulignement. En ce qui me concerne, c’est vraiment une question d’esthétique. Je (et beaucoup d’autres) trouve m_ laid, car il semble y avoir un trou dans le nom de la variable. C’est presque offensant. Je l’utilisais tout le temps dans VB6, mais c’était uniquement parce que les variables ne pouvaient pas avoir un trait de soulignement en tête. Je ne pouvais pas être plus heureux de le voir disparaître. Microsoft recommande de ne pas utiliser le m_ (et le droit _) même s’ils ont fait les deux dans leur code. De plus, le préfixe avec un “m” est tout droit. Bien sûr, comme ils codent principalement en C #, ils peuvent avoir des membres privés qui ne diffèrent que des propriétés. Les gens de VB doivent faire autre chose. Plutôt que d’essayer de trouver des cas particuliers de langue par langue, je recommande le trait de soulignement principal pour toutes les langues qui le prendront en charge. Si je veux que ma classe soit entièrement compatible avec CLS, je pourrais laisser le préfixe sur toutes les variables membres protégées par C #. En pratique, cependant, je ne me soucie jamais de cela car je garde toutes les variables membres potentiellement protégées privées, et je fournis plutôt des accesseurs et des mutateurs protégés. Pourquoi: En un mot, cette convention est simple (un caractère), facile à lire (votre œil n’est pas distrait par les autres personnages principaux) et évite avec succès les collisions de noms avec les variables de niveau procédure et les propriétés class.class au niveau de la classe. .

Le premier commentateur (R Samuel Klatchko) a fait référence: Quelles sont les règles d’utilisation d’un trait de soulignement dans un identifiant C ++? qui répond à la question sur le trait de soulignement dans C ++. En général, vous n’êtes pas censé utiliser un trait de soulignement en tête, car il est réservé à l’implémenteur de votre compilateur. Le code que vous voyez avec _var est probablement un code hérité, ou un code écrit par quelqu’un qui a grandi en utilisant l’ancien système de nommage, qui ne désapprouvait pas les caractères de soulignement principaux.

Comme d’autres réponses l’indiquent, il était utilisé en C ++ pour identifier les variables membres. Cependant, il n’a pas de signification particulière en ce qui concerne les décorateurs ou la syntaxe. Donc, si vous voulez l’utiliser, cela comstackra.

Je vais laisser la discussion C # aux autres.

_var n’a aucune signification et ne sert qu’à faciliter la distinction entre la variable membre privé et la variable.

En C ++, l’utilisation de la convention _var est une mauvaise forme, car il existe des règles régissant l’utilisation du trait de soulignement devant un identifiant. _var est réservé comme identifiant global, tandis que _Var (underscore + majuscule) est réservé à tout moment. C’est pourquoi, en C ++, vous verrez des personnes utilisant la convention var_ à la place.

Vous pouvez créer vos propres directives de codage. Écrivez simplement une documentation claire pour le rest de l’équipe.

Utiliser _field aide Intelilsense à filtrer toutes les variables de classe en tapant simplement _.

Je suis généralement les lignes direcsortingces Brad Adams , mais il recommande de ne pas utiliser de soulignement.

La norme de nommage de Microsoft pour C # indique que les variables et les parameters doivent utiliser la forme de casse inférieure de camel IE: paramName . La norme appelle également les champs à suivre le même formulaire, mais cela peut conduire à un code flou, de nombreuses équipes appellent un préfixe de soulignement pour améliorer la clarté. IE: _fieldName .

Avec C #, Microsoft Framework Design Guidelines suggère de ne pas utiliser le caractère de soulignement pour les membres du public . Pour les membres privés , les soulignés sont corrects à utiliser. En fait, Jeffrey Richter (souvent cité dans les directives) utilise par exemple un m_ et un “s_” pour les membres statiques privés.

Personnellement, j’utilise juste _ pour marquer mes membres privés. “m_” et “s_” sont proches de la notation hongroise, ce qui n’est pas seulement mal vu dans .NET, mais qui peut être très verbeux et je trouve difficile de faire un scan rapide des classes avec beaucoup de membres (imaginez 10 variables commençant par m_) .

En ce qui concerne les langages C et C ++, aucun trait de soulignement dans le nom (début, milieu ou fin) n’a de signification particulière. C’est juste un caractère de nom de variable valide. Les “conventions” proviennent des pratiques de codage au sein d’une communauté de codage.

Comme déjà indiqué par divers exemples ci-dessus, _ au début peut signifier des membres privés ou protégés d’une classe en C ++.

Permettez-moi de vous donner une histoire qui peut être amusante. Sous UNIX, si vous avez une fonction de bibliothèque C de base et un kernel du kernel où vous souhaitez exposer la fonction du kernel à l’espace utilisateur, _ est bloqué devant le stub de fonction qui appelle directement la fonction du kernel sans rien faire d’autre. L’exemple le plus connu et le plus connu est exit () vs _exit () sous les kernelx de type BSD et SysV: exit () effectue les tâches utilisateur avant d’appeler le service de sortie du kernel, alors que _exit correspond simplement au service de sortie du kernel.

Donc, _ était utilisé pour les éléments “locaux” dans ce cas, local était local à la machine. Généralement, les fonctions () n’étaient pas portables. En cela, vous ne devriez pas vous attendre à un comportement identique sur différentes plates-formes.

Maintenant, comme pour les noms de variables, tels que

int _foo;

Bien psychologiquement, un _ est une chose étrange à saisir au début. Donc, si vous voulez créer un nom de variable qui aurait moins de chance d’être en conflit avec quelque chose d’autre, surtout lorsque vous avez affaire à des substitutions de pré-processeur, vous devriez envisager d’utiliser _.

Mon conseil de base serait de toujours suivre la convention de votre communauté de codage afin de pouvoir collaborer plus efficacement.

Il n’y a pas de convention de dénomination particulière, mais j’ai vu cela pour les membres privés.

J’utilise le nommage _var pour les variables membres de mes classes. Il y a 2 raisons principales pour lesquelles je fais:

1) Cela m’aide à suivre les variables de classe et les variables de fonction locales lorsque je lis mon code plus tard.

2) Cela aide dans Intellisense (ou tout autre système d’achèvement de code) lorsque je cherche une variable de classe. Le simple fait de connaître le premier caractère est utile pour filtrer la liste des variables et méthodes disponibles.

Beaucoup de gens aiment avoir des champs privés préfixés par un trait de soulignement. C’est juste une convention de nommage.

Les conventions de dénomination «officielles» de C # prescrivent des noms simples en minuscules (pas de trait de soulignement) pour les champs privés.

Je ne suis pas au courant des conventions standard pour C ++, bien que les traits de soulignement soient très utilisés.

C’est juste une convention que certains programmeurs utilisent pour la rendre claire lorsque vous manipulez un membre de la classe ou un autre type de variable (parameters, local à la fonction, etc.). Une autre convention également utilisée pour les variables membres est le préfixe «m_».

Quoi qu’il en soit, ce ne sont que des conventions et vous ne trouverez pas une source unique pour tous. Ils sont une question de style et chaque équipe de programmation, projet ou entreprise a ses propres (ou même n’en ont pas).

Il y a une raison légitime de l’utiliser dans C #: si le code doit également être extensible depuis VB.NET. (Sinon, je ne le ferais pas.)

Puisque VB.NET est insensible à la casse, il n’existe pas de moyen simple d’accéder au membre de field protégé dans ce code:

 public class CSharpClass { protected int field; public int Field { get { return field; } } } 

Par exemple, cela va accéder à la propriété getter, pas au champ:

 Public Class VBClass Inherits CSharpClass Function Test() As Integer Return Field End Function End Class 

Heck, je ne peux même pas écrire de field en minuscule – VS 2010 ne cesse de le corriger.

Afin de le rendre facilement accessible aux classes dérivées de VB.NET, il faut trouver une autre convention de nommage. Préfixer un trait de soulignement est probablement le moins intrusif et le plus “historiquement accepté” de ceux-ci.

Maintenant, la notation utilisant “this” comme dans this.foobarbaz est acceptable pour les variables membres de la classe C #. Il remplace l’ancienne notation “m_” ou simplement “__”. Cela rend le code plus lisible car il ne fait aucun doute que la référence est en cours.

D’après mon expérience (certainement limitée), un trait de soulignement indiquera qu’il s’agit d’une variable membre privée. Comme Gollum l’a dit, cela dépendra de l’équipe, cependant.

Cela signifie simplement que c’est un champ membre dans la classe.

Une convention de nommage comme celle-ci est utile lorsque vous lisez du code, en particulier le code qui ne vous appartient pas. Une convention de dénomination forte aide à indiquer où un membre particulier est défini, quel type de membre il est, etc. La plupart des équipes de développement adoptent une convention de dénomination simple et _fieldName simplement les champs membres avec un trait de soulignement ( _fieldName ). Par le passé, j’ai utilisé la convention de dénomination suivante pour C # (basée sur les conventions de Microsoft pour le code .NET, visible avec Reflector):

Champ d’instance: m_fieldName
Champ statique: s_fieldName
Public / Protected / Internal Member: PascalCasedName ()
Membre privé: camelCasedName ()

Cela aide les gens à comprendre la structure, l’utilisation, l’accessibilité et l’emplacement des membres lors de la lecture de code peu familier très rapidement.