Directives de dénomination des champs en C# ?

Question

Je vais travailler seul sur un peu de code C#, mais je veux m'assurer que je respecte les conventions de dénomination les plus largement acceptées au cas où je voudrais faire appel à d'autres développeurs, publier mon code ou le vendre. Pour l'instant, je suis les conventions de dénomination établies par Microsoft, car elles semblent être les plus largement acceptées. La seule chose qu'ils ne mentionnent pas est le nommage des champs privés. La plupart du temps, je les ai vus nommés en majuscules comme les champs protégés, mais cela me pose un problème car les noms des paramètres doivent être en majuscules. Prenons l'exemple du constructeur suivant :

public GameItem(string baseName, string prefixName, string suffixName)
{
    //initialize code
}

Si j'utilise également la casse camel pour les champs privés, il y a un conflit de nom, à moins que j'utilise "this" pour accéder aux champs de la classe (ce qui, à mon avis, va à l'encontre de la plupart des normes, sans compter qu'il faut taper davantage). Une solution consiste à donner un nom différent au paramètre, mais cela n'a pas de sens logique de donner deux noms différents à la même donnée. La seule autre solution que je connaisse et qui était courante dans le codage C++ est de donner aux membres privés un trait de soulignement au début (_camelCase). Cette solution est-elle communément acceptée dans le codage C# ? Existe-t-il une autre solution à ce problème (comme utiliser uniquement les propriétés (qui utilisent la PascalCase) pour accéder aux champs, même dans la classe elle-même) ?

Answer 1

_camelCase pour les champs est courant d'après ce que j'ai vu (c'est ce que nous utilisons chez nous et Microsoft préférer pour le Runtime .NET ).

Je justifie l'utilisation de cette norme par le fait qu'elle est plus facile à taper. _ pour identifier un champ privé que this.

Par exemple :

void Foo(String a, String b)
{
    _a = a;
    _b = b;
}

Versus

void Foo(String a, String b)
{
    this.a = a;
    this.b = b;
}

Je trouve la première beaucoup plus facile à taper et elle m'empêche de jamais assigner accidentellement au paramètre appelé a au lieu de this.a . Ceci est renforcé par un Analyse du code Règle de maintenabilité qui stipule :

• CA1500 Les noms des variables ne doivent pas correspondre aux noms des champs.

Mon autre raison, c'est que this. est facultatif (Visual Studio / Code vous invite à les supprimer) s'il n'entre pas en collision avec une variable locale ou un nom de paramètre, ce qui rend plus difficile de savoir quelle variable vous utilisez. Si vous avez un _ au début de tous les champs privés, afin que vous sachiez toujours lequel est un champ et lequel a une portée locale.

Answer 2

Suivez les Directives de nommage de Microsoft . Le site directives pour l'utilisation des terrains indique qu'il doit être en camelCase et ne pas être préfixé. Notez que la règle générale est de ne pas utiliser de préfixe ; la règle spécifique est de ne pas utiliser de préfixe pour distinguer les champs statiques des champs non statiques.

N'appliquez pas de préfixe aux noms de champs ou aux noms de champs statiques. Plus précisément, n'appliquez pas de préfixe à un nom de champ pour distinguer les champs statiques des champs non statiques. Par exemple, l'application d'un préfixe g_ ou s_ est incorrecte.

et (de Conventions générales d'appellation )

N'utilisez pas de caractères de soulignement, de tirets ou tout autre caractère non alphanumérique.

EDIT : Je noterai que les docs ne sont pas spécifiques en matière de privé mais indiquent que protégé les champs doivent être en camelCase uniquement. Je suppose que vous pouvez en déduire que toute convention pour les champs privés est acceptable. Les champs statiques publics diffèrent certainement des champs protégés (ils prennent la majuscule). Mon opinion personnelle est que les champs protected/private ne sont pas suffisamment différents en termes de portée pour justifier une différence dans la convention de dénomination, d'autant plus que tout ce que vous semblez vouloir faire est de les différencier des paramètres. En d'autres termes, si vous suivez les directives relatives aux champs protégés, vous devrez les traiter différemment des champs privés afin de les distinguer des paramètres. J'utilise this lorsqu'il se réfère aux membres de la classe au sein de la classe pour que la distinction soit claire.

EDIT 2

J'ai adopté la convention utilisée dans mon travail actuel, qui consiste à préfixer les variables d'instance privées par un trait de soulignement et à n'exposer généralement les variables d'instance protégées que sous forme de propriétés utilisant PascalCase (typiquement autoproperties). Ce n'était pas ma préférence personnelle, mais c'est une convention avec laquelle je me sens à l'aise et que je suivrai probablement jusqu'à ce que quelque chose de mieux se présente.

Answer 3

En règle générale, il existe deux façons très répandues de nommer les champs (en utilisant toujours le terme camelCase ) :

Utilisation d'un préfixe de soulignement

void F(String someValue) {
  _someValue = someValue;
}

Utilisation de this. pour accéder au champ et éviter les conflits de noms

void F(String someValue) {
  this.someValue = someValue;
}

Personnellement, je préfère la dernière, mais j'utiliserai la convention établie par l'organisation pour laquelle je travaille.

Answer 4

Dans notre atelier, nous avons commencé notre premier projet C# en utilisant la ligne directrice suggérée par Microsoft pour les membres privés, à savoir

camelCaseFieldName

Mais nous avons rapidement rencontré une confusion entre les membres privés et les paramètres, et nous sommes passés à

_camelCaseFieldName

qui a bien mieux fonctionné pour nous.

Un membre privé possède généralement un état qui persiste en dehors d'un appel de méthode - le trait de soulignement en tête tend à vous le rappeler.

Notez également que l'utilisation de la syntaxe AutoVariable pour les propriétés peut minimiser la nécessité de champs de sauvegarde privés, c'est-à-dire

public int PascalCaseFieldName { get; set;}

Pour un ensemble concis de normes qui suivent (pour la plupart) les directives de la MS, consultez le site net-naming-conventions-and-programming-standards---best-practices

Answer 5

Norme de codage C# de Philips Healtcare

MSDN - Eric Gunnerson

Edit : J'utilise le mot clé "this" pour accéder aux membres non-statiques en C# et Java.