C#.NET convention de nommage des variables d'instance?
je fais un petit stage dans une entreprise et dans leur code je trouve des classes qui sont nommées comme ceci:
public class FlagsConfig
{
private static FlagsConfig _instance;
}
est-ce que le _instance
est une convention d'appellation quelconque dans C#?
je voudrais demander aux développeurs, mais ils sont tous aujourd'hui et la semaine prochaine sur certains cours.
12 réponses
peut-être que cela peut vous aider: ."
selon ce document, c'est ok.
Pour privé les membres, il y a beaucoup de différentes conventions. Certaines personnes aiment les préfixes, d'autres pas (personnellement, je ne le fais pas). Certains aiment faire la différence entre les variables d'instance et les variables statiques, d'autres pas:
private string m_foo;
private static string s_foo;
personnellement, je trouve les underscores obtenir dans la manière quand je lis le texte - et je crois fermement que cela dépend de comment vous lisez; Je subvocalise quand je lis, et les bits supplémentaires obtenir dans la façon de que. Pour d'autres, c'est clairement pas un problème. D'autres trouvent que le manque de distinction entre les variables locales et les variables des membres est un problème - j'écris généralement des méthodes courtes où il est évident ce qui est quoi de toute façon.
ce qui est plus important - certainement si vous créez une API etc est le nom des membres publiquement visibles (qui comprend les protégés, et les noms de paramètres) à quel point vous devriez regarder le Microsoft guidelines .
Est le _instance une convention de nommage de toute sorte en C#?
tout d'abord, un certain nombre de personnes ont fait référence aux directives de nommage. Il est à noter que bon nombre de ces lignes directrices ne s'appliquent qu'à la surface publique d'un type. Les membres privés comme celui que vous mentionnez sont des détails internes de mise en œuvre et donc soumis aux politiques de l'organisation qui les a produits, non soumis à la conception du cadre lignes directrices pour que les gens s'attendent à voir dans un élément public.
Pour les détails de mise en œuvre le trait de soulignement préfixe est commun dans de nombreuses organisations. Personnellement, je ne pense pas que c'est nécessaire, mais certaines personnes semblent aimer ça.
ce qui est important cependant est que même pour les détails de mise en œuvre privée, vous ne devriez jamais utiliser deux sous-barres. l'équipe du compilateur C# se réserve le droit de faire n'importe quel mot qui commence par deux sous-titres pour avoir tout le sens que nous choisissons dans une version future de la langue. C'est notre "échappatoire" dans le cas où nous avons vraiment, vraiment besoin d'ajouter un nouveau mot-clé réservé Non-contextuel et vraiment, vraiment ne voulons pas casser un code existant.
ceci est documenté dans la section 2.4.2 de la spécification C# 4.
Oui, c'est une norme d'appellation courante pour les champs privés:
http://csharpguidelines.codeplex.com /
il se trouve que je suis d'accord avec @JonSkeet que les underscores sont désordonnés, mais AFAIK c'est la norme MS. Le document auquel il renvoie indique et non en utilisant des caractères soulignés dans votre bibliothèque, mais je crois que cela fait référence aux membres du public.
mise à Jour
le premier lien prône en fait le contraire; n'utilisez pas de soulignement. Mon erreur, mais c'est toujours une ressource utile.
par respect pour M. Skeet, j'ai suivi son lien plus loin: http://msdn.microsoft.com/en-us/library/ms229012.aspx qui stipule également qu'il ne faut pas utiliser de soulignements, mais que les directives s'appliquent aux membres statiques, protégés et publics, mais pas nécessairement aux membres privés.
"Bottom Line : Oui il s'agit d'une norme commune, mais utilisez d'abord toute norme convenue à l'interne avant d'essayer de trouver/d'utiliser des normes externes.
il y a beaucoup de lignes directrices et de normes à choisir, mais si la norme utilisée dans votre milieu de travail met en évidence, alors c'est ce que vous devez utiliser. Surtout si vous ne faites qu'un stage là-bas, l'objectif devrait être de garder les choses cohérentes (au sein de cette entreprise) plutôt que de suivre une norme qui est "meilleure" (mais différente).
peut-être que la meilleure question à poser à vos développeurs (ou aux patrons supérieurs) est de savoir s'ils ont documentation/liens sur les normes qu'ils utilisent?
_name
est désordonné, confus et très ancienne. ne pas le faire.
.NET 4.0 conventions générales D'appellation http://msdn.microsoft.com/en-us/library/ms229045.aspx
comme vous pouvez le voir, MSDN dit
n'utilisez pas les caractères soulignés, les traits d'Union ou tout autre caractère non-alphanumérique
c'est relativement courant d'après mon expérience. Pour aider à identifier des types particuliers de variables (privates, paramètres de méthode, etc.), un développeur peut employer des conditions de nommage différentes.
p.ex.
- VariableName
- variableName (camel cas)
- _variable
- NOM_VARIABLE
elle tend à varier selon l'entreprise je pense.
j'aime utiliser un cas de changement de la distinction entre les champs et les propriétés:
// A private field
private Boolean someValue;
// A public property, exposing my private field
public Boolean SomeValue {
get { return someValue; }
set { someValue = value; }
}
vos collègues sont-ils des ex-VB devs? En VB.Net le trait de soulignement est utilisé régulièrement pour les membres privés de propriétés ou de classes. Puisque VB est insensible à la casse, vous ne pouvez pas utiliser case pour distinguer.
Private _someValue As Boolean
Protected Property SomeValue() As Boolean
Get
Return _someValue
End Get
Set(ByVal value As Boolean)
_someValue = value
End Set
End Property
mise à jour: de nombreuses classes du code source.net utilisent cette convention. Surtout dans le système .Web .
il existe deux conventions communes.
la première est d'Utilisateur "trait de soulignement comme marqueur de champ" la seconde est "utiliser s_ pour les champs statiques et m_ pour les champs d'intance"
imo c'est une question religieuse et seule chose importante est de ne pas mélanger les deux styles.
Ce livre contient beaucoup de bonnes idées au sujet de la convention et des lignes directrices de conception
il y a beaucoup de conventions d'appellation que les gens suivent
myFirstVar = Camel Notation
Chameau notaion est généralement utilisé pour les variables publiques (pas de variables privées).
MyFirstVar = Pascal Notation
Pascal est généralement utilisé pour nommer les Classes et les méthodes.
str_MyFirstVar = Hungarian Notation // if variable is of type string
la Notation hongroise est considérée comme la plus ancienne mais n'est plus utilisée.
_myFirstVariable = used for private fields in general
selon StyleCop [un outil de vérification de style/convention par Microsoft) il ne devrait pas être fait. Voir: http://stylecop.soyuz5.com/SA1309.html
aussi, question est un dupe possible de à souligner ou à ne pas souligner, c'est la question