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

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.)

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 _.

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.

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

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;
}

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.

private int integer

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

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!

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

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;

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.

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.

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.

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.

Je passe par l'option 5: private int _MyFoo

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

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

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.

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.