Sur les conventions d'appellation C # pour les variables membres
J'ai vu un conseil quelque part ici sur SO pour ne pas nommer les variables membres private/public, D'une manière qui ne diffère que par le cas du tout premier caractère. Par exemple:
private string logFileName;
public string LogFileName
{
get
{
return logFilename
....
et: private System.Windows.Forms.MainMenu mainMenu;
et: DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();
et:
public Version Version
{
get;
set;
}
et:
private void CheckPollingType(PollingType pollingType)
{
Alors, ai-je mal entendu? Y a-t-il un problème avec ces conventions de dénomination? Si oui, quelles sont les meilleures façons de le faire? Liens, références sont un plus.
Merci.
C'est certainement une convention de dénomination très populaire et je ne vois pas pourquoi vous devriez être contre.
Je recommanderais simplement de suivre les Conventions de dénomination pour C # fournies par MSDN et aussi Conventions générales de dénomination fournies par MSDN .
Plus précisément, ils ont ceci à dire sur les propriétés:
Nommez les propriétés à l'aide d'un nom, d'une expression nominale ou d'un adjectif.
Les expressions ou adjectifs de nom sont appropriés pour les propriétés car les propriétés contiennent des données.
N'utilisez pas de propriétés correspondant aux noms des méthodes Get.
Par exemple, ne nommez pas une propriété EmployeeRecord et nommez également une méthode GetEmployeeRecord. Les développeurs ne sauront pas quel membre utiliser pour accomplir leur tâche de programmation.
Nommez les propriétés booléennes avec une phrase affirmative (CanSeek au lieu de CantSeek). Facultativement, vous pouvez également préfixer les propriétés booléennes avec Is, Can ou Has, mais uniquement là où cela ajoute de la valeur.
Pensez à donner à une propriété le même nom que son type.
Lorsque vous avez une propriété fortement typée sur une énumération, le nom de la propriété peut être le même que le nom de l'énumération. Par exemple, si vous avez une énumération nommée CacheLevel, une propriété qui renvoie l'une de ses valeurs peut également être nommée CacheLevel.
Je pense que s'il y avait une raison impérieuse d'être contre ce que vous suggérez, ils l'auraient mentionné dans leurs lignes directrices.
La plupart des variables de niveau de classe temporelle sont précédées d'un trait de soulignement. Donc myVariable est en fait _myVariable. Beaucoup de gens n'aiment pas faire varier le nom d'un caractère, car il est trop facile de se tromper.
Il n'y a rien de mal à simplement faire myVariable et MyVariable. Ce n'est qu'une convention, et si tout le monde la suit, cela fonctionnera probablement très bien.
Personnellement, si possible, je me passe de la variable privée et j'utilise simplement les getters et setters dans la propriété. La plupart du temps (mais pas tout le temps), l'accès à la variable privée était utilisé pour ne pas autoriser l'accès en écriture dans la propriété.
Cela peut être résolu par:
public String MyVariable
{
get;
private set;
}
En règle générale, je vois toujours des membres privés avec un _. (en supposant que ce n'est pas une propriété automatique)
private string _customerName;
public string CustomerName
{
get{return _customerName;}
set{_customerName = value;}
}
Bien sûr, le verdict final est la convention de votre équipe (en supposant que vous ne faites pas un projet de loup solitaire ou que vous ne travaillez pas avec des crétins)
Je jetterai mon chapeau dans le ring avec ce que j'ai toujours utilisé
class ClassName //Classes are PascalCase
{
public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
{
_myProperty = myPropriety;
}
public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
{
int sampleVar; //local variables are camelCase
}
public int MyProperty { get { return _myProperty; } } // Properties are PascalCase
private int _myProperty; // Private fields are camelCase and start with a _
Non, il n'y a rien de mal à ces conventions de dénomination.
La version de la propriété est en fait le format recommandé selon les directives de conception du framework .Net.
La déclaration de champ est également conforme aux directives du cadre car elle est camelCased. C'est parfois un peu une guerre religieuse pour savoir si la variable doit être préfixée par un _ ou m_. C'est une question qui doit cependant être résolue au sein de votre groupe.
Lignes directrices de conception de framework .Net pour les membres de type
Une raison pour laquelle je peux penser à ne pas utiliser la casse pour différencier les membres publics des membres privés est que Visual Studio Intellisense triera les deux membres côte à côte, de sorte que vous pourriez utiliser le mauvais sans le remarquer.
Cela étant dit, j'utilise la convention que vous avez décrite (en utilisant la casse pour différencier l'accessibilité) dans mon code, et je n'ai eu aucun problème.
Si vous ne faites que du C #, ce n'est pas un problème, mais si vous (ou votre équipe/entreprise) faites également du VB.Net (qui n'est pas sensible à la casse), alors je recommanderais qu'il serait préférable de ne pas le faire en C # soit pour que les conventions de nommage entre les différentes langues ne diffèrent pas trop.
Les deux conventions les plus courantes que je vois sont le préfixe des variables de membre privé avec un _ ou un m_. Personnellement, je préfère la convention m_, mais tant qu'elle est cohérente dans l'ensemble du projet/de l'équipe, je m'en fiche. Je ne suis pas du genre à entrer dans des "guerres de religion" :)
Quelle que soit la convention de dénomination que vous choisissez, soyez cohérent. Ensuite, au moins lorsque vous reviendrez au code dans six mois ou lorsque quelqu'un de nouveau le consultera pour la première fois, il pourra déterminer ce qui est quoi.
Attention cependant à ce scénario:
public class MyClass {
public int Foo { get; private set; }
public MyClass(int foo) {
// oops, setting the parameter to itself, not the property
foo = foo;
}
}
Visual Studio vous avertira de cette situation, mais ce n'est pas illégal et peut parfois vous échapper.
le problème principal avec le même nom avec une casse différente est que toutes les langues dans .net ne sont pas sensibles à la casse, c'est-à-dire Visual Basic.
Le seul scénario où c'est un vrai problème est lorsque vous exposez des membres du public qui ne varient que par cas. Il existe un attribut de compatibilité que l'on peut définir afin que le compilateur vous indique si vous avez l'un de ces scénarios.
Ci-dessus, cela n'affecte pas vraiment le scénario du membre privé de soutien.
Le problème de base avec la convention de dénomination proposée est qu'Intellisense utilisera la variable privée sur la propriété. Dans de nombreux cas, ce n'est pas vraiment un problème (c'est, en fait, généralement une bonne chose), mais pour les quelques cas où c'est le cas, une convention qui sépare les deux noms est utile. J'aime m_ pour les variables de membres privés et c_ pour les variables statiques privées.
Comme cela apparaît parmi les meilleurs résultats de recherche concernant le sujet, je voulais également partager ma suggestion:
En plus de la convention Pascal/camelCase pour les membres publics/privés, je choisis toujours les noms de variables membres qui se composent de 2 mots ou plus, et les noms de variables locales qui se composent d'un mot minuscule unique ou même juste une lettre.
public class MyCanvas : Canvas {
public int CanvasId { get; private set; }
private double canvasHeight; // member vars consist of 2+ words
private double canvasWidth;
public MyCanvas(int id) {
CanvasId = id;
double height = ...; // local vars consist of one Word/letter
canvasHeight = height;
}
}
Cela permet de choisir des noms de variables cohérents et significatifs, sans préfixes "drôles" comme _, mais aussi pour faire la distinction entre les variables locales et les variables membres.