Comment nommez-vous vos variables privées en C #? [fermé]


25

Quelle est la meilleure pratique, les conventions de dénomination les plus couramment acceptées pour les variables privées en C #?

  1. private int myInteger;
  2. private int MyInteger;
  3. private int mMyInteger;
  4. private int _myInteger;
  5. private int _MyInteger;
  6. Mystérieuse autre option

Lequel utilisez-vous et pourquoi? (Mon entreprise est relativement nouvelle en C # et je voudrais choisir la méthode la plus "acceptée par l'industrie" pour essayer de pénétrer notre norme de codage.)


Pourquoi ne pas utiliser les propriétés implémentées automatiquement? msdn.microsoft.com/en-us/library/bb384054.aspx
Kyle Ballard

1
C # a des normes pour cela, voir stackoverflow.com/questions/14967/…
Tamara Wijsman

7
Ce n'est pas agréable de parler de variables privées en public. Désolé, je devais juste.
Mark C

J'utilise la même chose que azheglov (m_someVariable) à l'exception de j'utilise uniquement _someVariable dans la portée locale d'une méthode.
lord-fu

7
@Mark Je pense que cela devrait être "privé" pour que cela soit suggestif.
EpsilonVector

Réponses:


44

Les directives de conception de classe MSDN http://msdn.microsoft.com/en-us/library/ta31s3bc.aspx recommandent l'option 1 - myInteger.

J'ai toujours utilisé ce style. J'ai une aversion personnelle pour le caractère _.


1
J'ai détesté le caractère _ jusqu'à ce que resharper ajoute une correspondance de mi-chaîne à l'intellisence. Maintenant je peux taper myIntegeret ça va correspondre _myInteger. Mais je ne savais pas que MSDS dit de ne pas utiliser le _
Vaccano

4
Si vous utilisez l'option 1, comment savoir si myIntegerune variable est locale à une méthode ou à un membre d'une classe privée?
Wizard79

4
@Lorenzo this.myInteger;)
TWith2Sugars

12
Mais mais ... "ceci" est de 4 caractères et "_" n'en est qu'un! En fait, cette directive a beaucoup de sens, mais dans mon bureau, tout le monde aime souligner et déteste voir "this.Foo", pour une raison quelconque. Parfois, les seules directives qui comptent sont celles que votre lieu de travail vous impose.
CodexArcanum

2
L'argument sur le nombre de caractères est discutable. Vous n'avez pas à taper à thischaque fois, uniquement dans les méthodes où une variable locale avec le même nom est présente. Cependant, vous devez écrire un symbole supplémentaire à chaque fois si vous utilisez un trait de soulignement. Avec ce que je suis d'accord, c'est qu'il est toujours important de respecter votre accord de style de code local.
Malcolm

25

J'utilise l'option # 4 ci-dessus:

private int _myInteger;

J'aime avoir une indication de la portée dans mes noms de variables, et le soulignement est suffisant à cet effet. C'est aussi assez facile à lire.


5
Je ne suis pas d'accord pour dire qu'il est facile à lire, surtout si vous devez opérer avec plusieurs variables.
Restuta

15

J'utilise le schéma de dénomination suivant:

  • 1er (myInteger) pour les variables de portée locale
  • 2e (MyInteger) pour les propriétés publiques
  • 4ème (_myInteger) pour les variables privées

14

Je pense que l'option 4 est vraiment l'option la plus lisible. Cela vous aide d'avoir à le faire:

public Person(string name, int age) 
{
    this.name = name;
    this.age = age;
}

Cela rend également tous les membres privés plus visibles. Dans l'exemple suivant, d'où vient le diable age? Sans le thisqualificatif, c'est plus difficile à dire.

private void Method()
{
    var x = 2;
    var y = age + x;
}

C'est beaucoup plus facile à comprendre:

private void Method()
{
    var x = 2;
    var y = _age + x;
}

1
J'ai juré par votre premier exemple, mais après avoir essayé l'option # 4 pendant un certain temps, je préfère de loin utiliser les traits de soulignement comme préfixe pour les champs privés.
Jeremy Wiebe

2
Je dis, utilisez 1 pour les variables privées, utilisez 4 pour les variables privées utilisées dans les propriétés.
Evan Plaice

2
Je dois être en désaccord avec ChaosPandoin. Pour moi, les deux implémentations de Method () sont faciles à lire. Dès que je vois la variable age (ou _age) et que je remarque qu'elle n'est pas déclarée dans la méthode, je me rends compte qu'elle doit être déclarée ailleurs dans la classe. Le qualificatif this est horrible mais au moins il est limité à la méthode constructeur.
David Kennedy

10

Tout d'abord, PascalCasing est généralement réservé aux propriétés publiques, consts, méthodes, etc. de la classe. Je sauterais donc 2 et 5.

Deuxièmement, la notation hongroise est découragée dans le monde .NET, donc (euh, je pense) 3 est tout de suite sorti. En supposant que c'est ce qui se passe avec 3.

Cela laisse avec camelCasing et _camelCasing. J'utilise généralement _camelCasing pour les variables de classe, et plain old camelCasing pour les variables limitées à une méthode ou plus étroite. Le chameau est le standard accepté utilisé pour les arguments de méthode, les noms de variable protégés / privés et les variables dans une méthode ou une portée plus étroite.

J'aime aussi ajouter le trait de soulignement pour que mes variables privées soient regroupées dans mon intellisense. Cependant, je ne fais cela que pour les variables limitées à un type. Variables déclarées dans une méthode ou une portée plus étroite Je laisse le trait de soulignement désactivé. Il est facile de les séparer et de regrouper les variables moins utilisées.


2
Je ne comprends pas pourquoi vous utiliseriez _camelCasing pour les variables de classe, car il est généralement évident qu'il s'agit de variables de classe.
alternative

1
@math non, ce n'est pas évident dans l'intellisense. N'oubliez pas que les champs (variables de portée de classe) ont (presque) la même icône que les variables de portée de méthode, ils ont donc exactement la même apparence si vous n'y regardez pas de près. Le trait de soulignement permet de les différencier visuellement et de les garder groupés, ce qui est utile si vous ne les utilisez pas souvent (ce que vous ne devriez pas être car l'état est l'ennemi de la programmation sans bogue).
Déchiré le

Je n'ai jamais rien dit sur l'Intellisense. Je parle de la différence entre Color.ClassMethod () et myColor.InstanceMethod (), à savoir qu'il devrait être évident que puisque Color est une classe, ClassMethod () est une méthode de classe.
alternative

@math you before: I don't understand why you would use _camelCasing for class variables you after: I'm talking about the difference between Color.ClassMethod() and myColor.InstanceMethod()Excusez-moi pendant que je suis confus. Écoutez, j'utilise rarement les variables de classe, il est donc agréable de se souvenir de leurs noms en appuyant sur _ et en les faisant tous apparaître dans l'intellisense gentil et groupé.
Déchiré le

2
@mathepic: Quand Will dit "variables de classe", il veut dire des champs d'instance (privés). Vous semblez avoir interprété ce qu'il a dit comme des membres statiques; mais ce n'est pas ce qu'il a dit.
Dan Tao

4

private int integer

Si vous vous trompez entre les variables membre et locales dans une portée de méthode, vous devrez probablement refactoriser.


+1: c'est ce que je crois être le point. BTW: Je vois sa source, mais le nom integerpourrait être mieux reformulé, peut value- être ?
Loup

2

Je crois que la meilleure façon de le faire (en C # /. Net de toute façon) est une combinaison de 2 et 6:

private int MyInteger { get; set; }

Il n'y a théoriquement aucune variable ici, mais elle ressemble et agit comme une variable d'instance privée. Si nous devons ajouter une logique métier à cette valeur (c'est une valeur complètement interne, donc nous pouvons faire tout ce que nous voulons après tout), alors elle est déjà «propriété» pour nous. Une tasse de victoire chaude et fumante!


2

Je fais l'option # 4 parce que c'est à cela que ressemble le SSCLI, mais honnêtement, je ne me soucie pas beaucoup de nommer une variable privée. Le public est une autre histoire.

BTW vous avez oublié m_MyInteger


2

Je ne l'appellerais "rien"!

Mais je dirais

class C
{
     int VariableName { get; set; }
}

assez souvent c'est plus agréable que d'avoir des variables explicites. Si j'avais une variable privée explicite, je l'appelleraisint _variableName;


1

En C ++, j'ai tendance à utiliser _ car je change beaucoup d'éditeurs, ce qui ne me permet pas de voir si c'est privé.

Pour C #, j'ai tendance à laisser le _ loin car Visual Studio me permet de voir s'il est privé.

J'ai tendance à utiliser la méthode Camel Case pour ce faire.


1

J'utilise 4 ( private int _myInteger;) car:

private int myInteger;

C'est ainsi que je nomme mes variables locales.

private int MyInteger;

C'est ainsi que je nomme les constantes.

private int mMyInteger;

Ce n'est pas du style C #.

private int _MyInteger;

Cela a l'air étrange.


1

avec le trait de soulignement.

Bill Wagner explique pourquoi dans Effective C # . Mais je ne nommerais jamais un entier mon entier , mieux quelque chose comme _age ou _length. Inclure le TypeName dans le nom de l'instance est une pratique horrible. Les noms doivent être explicites et puisque C # est de type sûr, les types peuvent être trouvés à tout moment.


1
Oui, c'était un exemple.
Vaccano

1

Vous devez donner un exemple plus spécifique, mais:

private int count, private int badFileCount,private static readonly int ReconnectAttemptsLimit

Soit dit en passant, vous obtenez tout cela GRATUITEMENT lorsque vous installez et commencez à utiliser la dernière et la meilleure MSFT Stylecop.


0

Je passe par l'option 5: private int _MyFoo

Je ne vois cependant aucun réel avantage concurrentiel sur _myFoo.


0

Utilisez camelCasing pour des variables privées comme myInteger

Considérez un précédent _si la variable est une sauvegarde pour une propriété afin de réduire les confusions -
Variable _myPropertypour la propriétéMyProperty


0

J'ai ReSharper nommer mes variables, non seulement la mienne mais tout le monde le fait aussi. Il y a une grande cohérence dans le projet.


0

La norme de codage IDesign C # de Juval Lowy est très populaire. Cette norme recommande de préfixer les variables de membre privé avec "m_" (Option 6). C'est ce que nous faisons dans notre équipe.

private int m_myInteger;

Option 4 (_myInteger ) est une variante acceptable de cette norme.

Je n'ai pas aimé la recommandation MSDN ( myInteger), car il est difficile de distinguer un membre privé d'une variable locale. Leur recommandation, bien sûr, résout ce problème en qualifiant les députés privés this, ce qui me semble redondant.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.