Quelle est la convention de nommage des champs statiques C #?
J'ai récemment commencé à utiliser ReSharper, un outil fantastique. Aujourd'hui, je suis tombé sur une règle de nommage pour les champs statiques, à savoir préfixer par un trait de soulignement, par exemple.
private static string _myString;
- Est-ce vraiment la manière standard de nommer des variables statiques? Si c'est le cas, s'agit-il uniquement de préférences personnelles et de style, ou est-ce que cela a un impact moindre? Par exemple, Compilation JIT etc?
- D'où vient ce style? Je l'ai toujours associé au C++, est-ce correct?
Les directives de Microsoft ne disent rien sur les champs privés, elles concernent uniquement les membres visibles publiquement.
Les conventions courantes sont camelCase, _camelCase et même parfois la solution de rechange de C++/MFC m_camelCase.
Si vous utilisez camelCase sans préfixe, les champs de sauvegarde de votre propriété ne différeront du nom de la propriété que dans le cas contraire, ce qui ne pose pas de problème en C #, mais ne fonctionnera pas dans un langage ne respectant pas la casse, comme VB.NET.
Tant de gens, y compris moi-même, préfèrent utiliser un préfixe de soulignement pour que les mêmes normes puissent être utilisées dans toutes les langues. D'après mon expérience, le soulignement est beaucoup plus courant que m_.
Selon MSDN , utilisez Pascal Case pour les champs statiques. Je ris toujours lorsque MSDN et StyleCop se contredisent :).
Par conséquent, si vous suivez les normes MSDN, procédez comme suit:
private static string MyString;
Selon StyleCop (et avec les paramètres par défaut), la manière correcte de nommer la plupart des champs (comme spécifié ci-dessous) consiste à utiliser une lettre minuscule au début.
SA1306: FieldNamesMustBeginWithLowerCaseLetter
... Les noms de champs et de variables doivent commencer par une lettre minuscule, sauf si le champ est public ou internal, const ou non privé et en lecture seule. Dans ces cas, le champ doit commencer par une lettre majuscule.
Voir aussi SA1309: FieldNamesMustNotBeginWithUnderscore .
C'est en fait le style d'un champ private , statique ou non. (Au moins dans ReSharper)
La convention correspond à toutes les normes de codage de votre entreprise.
Le problème que j'ai avec la directive MSDN (utiliser le cas Pascal) est qu'il en résulte qu'il n'y a aucune distinction entre une variable statique privée et une propriété publique (non statique). Le même problème se poserait pour les propriétés statiques - pas de distinction entre statique et non statique.
C'est peut-être délibéré?
Une solution serait d'utiliser la même norme pour la statique que pour la non-statique, mais de toujours qualifier l'utilisation de la statique en préfixant le nom de la classe. Il peut y avoir quelques caractères supplémentaires à taper, mais cela rend le code plus lisible. Par exemple:
public class Employee
{
private static Int32 thresholdPercentage = 5;
public static String TooMuchMessage = "Unacceptable pay rise - sorry!";
private Decimal _salary = 0.0m;
public void RaiseSalary(Int32 raiseAmountPercentage)
{
if (raiseAmountPercentage > Employee.thresholdPercentage)
throw new ApplicationException(Employee.TooMuchMessage);
_salary *= 1 + (raiseAmountPercentage / 100);
return;
}
}
Pour les champs static , j'ai opté pour StaticPascalCase (par exemple, StaticPersonCache), qui le distingue clairement d'une variable d'instance. Cela inclut les champs statiques privés ainsi que les champs statiques avec d’autres modificateurs de visibilité.
Pour les variables statiques, le fait d'indiquer la visibilité publique/privée à travers le nom me préoccupe moins que d'indiquer comment la variable fonctionne entre les instances. De plus, comme il n’ya pas (et ne devrait pas en avoir) beaucoup de variables statiques, le modificateur «de type Hugarian» n’est pas souvent appliqué.
De même, pour thread static variables ([ThreadStatic] ou ThreadLocal), la convention que j'utilise est TS_UpperCamelCase (par exemple, TS_Random). Une fois encore, cette "rupture" avec les normes transmet des informations très importantes que les autres développeurs pourraient ne pas voir au premier abord. Le nom est donc utilisé comme un drapeau de mise en garde.
J'utilise ReSharper et ai ajusté les avertissements/astuces en conséquence; la plupart des autres conventions de dénomination sont conservées avec les paramètres par défaut de ReSharper.
Ma sélection de conventions "non standard" pour les champs static/thread-static (note: Microsoft utilise TS_ dans certains codes de la bibliothèque .NET) est due au fait que j'ai rencontré plus d'un "problème" en raison de erreur d'identification des variables Static/ThreadStatic/Instance: c'est beaucoup plus difficile à faire avec StaticX, TS_X et _x.
Les autres réponses ici sont un peu déroutantes.
De .NET standard :
NE PAS utiliser PascalCasing dans les noms de champs.
Les directives de dénomination de champ s'appliquent aux champs publics et protégés statiques.
Ainsi, l'exemple sera: MyStaticVariable, ActiveUserCount, etc.
1 - Il n’existe pas de règle standard définitive pour les noms de variables. Il existe des exigences en matière de compilateur C # pour ce qui est autorisé et ce qui n'est pas autorisé (c'est-à-dire, ne peut pas commencer par un nombre), mais les règles de style de langage de programmation sont généralement laissées aux programmeurs/organisations. ReSharper a des règles de style prédéfinies; Cependant, ils sont simplement configurés comme valeurs par défaut dans une approche convention sur configuration et sont modifiables.
2 - Vous pouvez jeter un oeil à cet article de Wikipédia pour voir l’histoire derrière Camel Casing .