C# les normes de codage pour les variables de membre privées

J'ai vu deux approches communes pour les normes de codage pour les variables de membre privées:

class Foo
{
    private int _i;
    private string _id;     
}

et 

class Foo
{
    private int m_i;
    private string m_id; 
}

Je crois que le dernier est à venir à partir de C++. Aussi, beaucoup de gens spécifier le type avant de la variable de membre (par exemple,double m_dVal) pour indiquer que c'est un non-constante variable membre de type double?

Quelles sont les conventions en C#?

  • Le lièvre n'est PAS exacte en double que je demande un cas général, et pas seulement m_. thx pour souligner le lien si...
  • Que "dupe" a été fermé en S&A. Cette question est valable (et driis' réponse a été très utile, je pourrais ajouter).
InformationsquelleAutor | 2009-04-13
  1. 61

    Outre les deux que vous mentionnez, il est très commun en C# pour ne pas avoir un préfixe pour les membres privés. 

    class Foo
{
    private int i;
    private string id; 
}

    Qu'est ce que j'utilise, et aussi ce qui est recommandé dans Internes de Microsoft règles de nommage.

    • D'accord, avec la seule exception que, personnellement, j'ajoute un caractère _ quand le secteur privé est membre de la mémoire de sauvegarde pour une propriété publique.
    • Je préfère le souligner parce que j'aime connaître la portée de la variable juste en regardant le nom
    • J'ai aussi toujours utiliser un trait de soulignement préfixe pour les biens champs de sauvegarde, comme il est facile de faire une erreur et d'obtenir un... stackoverflow hur 😉
    • Puntastic meandmycode... 🙂
    • Au moins en Java, vous pouvez laisser le compilateur se plaindre membre accède sans le "cette." qualificatif. Je préfère "cette.x" sur "_x" (ce qui est encore ambiguë).
    • vous pouvez utiliser this. en C# aussi. Rend le _ 'fudge' redondant si vous me demandez...
    • "je" ne doit jamais être utilisé comme une variable. Ni devrait a, b, c, d, ... je pourrais dire imaginaire ou un entier, ce qui est ambigu. Toujours préciser vos noms de sens et de ne jamais utiliser des abréviations! Le seul endroit où les abréviations de l'aide est en situation de non-compilé les langages de script (javascript, perl, bash, php, SQL, par exemple). Id est assez standard, mais assurez-vous de la balise <CLSComplient> _ ou [CLSComplient] en face de votre classe. Depuis ce ne sera pas signaler toutes les erreurs pour les champs privés, votre libre de faire quoi que ce soit. Toujours choisir un standard de tout le monde sur le projet d'accord. Set avant de commencer/se joindre.
    • i ne doit jamais être utilisé comme une propriété ou un nom de champ. Cependant, il est de pratique courante d'utiliser une variable nommée i l'itération d'une boucle for (et même j pour une boucle imbriquée). La seule fois où j' ne pas ne c'est lors d'une itération dans un 2D/3D de la grille, dans ce cas, je voudrais utiliser x, y, z.
    • La classe "Toto", mais la prochaine méta-var est "je"? Votre exemple de style est mauvais comme votre réponse.
    • J'aime le trait de soulignement préfixe parce qu'il garde la saisie semi-automatique de changer mes propriétés en stackoverflows...
    • Les lignes directrices de Microsoft vous référencées sont maintenant très ancienne, et ne s'appliquent plus. Interne et des champs privés sont expressément exclus de Microsoft règles de nommage comme indiqué ici.
    • Oui, la réponse est près de 10 ans 😉 néanmoins, je pense que le suggestion de ne pas utiliser un préfixe est encore solide, même si MS n'a pas l'inclure dans leurs intitulés.
    • Pourquoi?....

    InformationsquelleAutor driis
  2. 14

    Comme l'a noté Brad Abrams: interne des directives de codage:

    Ne pas utiliser un préfixe pour les membres
    variables (_, m_, s_, etc.). Si vous
    souhaitez distinguer entre le local et le
    membre des variables, vous devez utiliser
    “this.” en C# et “Me.” dans VB.NET.

    • Radolph: Semble qu'ils ont implicitement interne ligne directrice: ne pas utiliser VB 🙂
    • J'imagine qu'ils le doivent. Je voudrais avoir un lien, mais j'ai lu une recommandation en ce cas ne pas être utilisé comme seul facteur de distinction en C# pour maintenir interopt de compatibilité.
    • Brouillard: Oui. C'est pour public les membres, bien que. Vous ne devriez pas avoir de deux membres du public qui sont différentes que dans cas. Il n'est pas conforme CLS.
    • +1 pour @Steve pour noter cela s'applique aux membres du public et les CLS de la conformité. Membres privés ont beaucoup plus de liberté. C# ou VB.net. Rien d'autre ne doit accéder directement à eux. Mais assurez-vous d'être cohérent tout au long du projet. Et toujours le code pour la prochaine personne à prendre le dessus.
    • À l'aide de cas que la seule distinction entre les membres de la classe est une pratique horrible, indépendamment du fait que la langue prend en charge.
    InformationsquelleAutor Mehrdad Afshari
  3. 13

    Je pense que l'important principe ici est que vous êtes cohérent. L'utilisation d'un "_" ou "m" préfixe si c'est ce que vous aimez faire et c'est cohérent avec le reste du code que vous travaillez avec. Quel que soit votre choix, rester avec elle et être cohérent.

    • amen. La cohérence est la seule norme qui est nécessaire.
    InformationsquelleAutor Brandon Montgomery
  4. 10

    Je préfère utiliser votre premier exemple, ou de l'auto-propriétés de ce type, ce qui évite d'avoir privé les champs définis dans votre classe à tous:

    public String MyString { get; set; }

    Utiliser le prop extrait de rendre ces VRAIMENT rapide.

    • Fonctionne sauf que vous ne pouvez pas faire de l'auto de propriétés en lecture seule... ah bien, je vais peut-être chercher dans C# 5.0.
    • Vous pouvez les faire en "lecture seule" en faisant de l'ensemble privées ou protégées: public String MyString { get; private set; }
    • +1 je ne connaissais pas ce morceau de code, merci!
    • Sauf qu'ensuite, ils ne sont pas précisément en lecture seule, une méthode de classe peut toujours le réinitialiser.
    • Une méthode de classe peut également définir un champ privé ... quelle est la différence?
    • Je suppose que @Michael signifiait en lecture seule dans le sens d'être directement inmodifiable à l'extérieur de la classe, et non pas le mot clé readonly. La surcharge de mots anglais à l'œuvre ici. 🙂
    • Oui, je voulais dire ceci: private readonly chaîne foo;public String MyString { get { return foo; } }

    InformationsquelleAutor Daniel Schaffer
  5. 7

    Que je me souviens de la lecture de Cadre Des Lignes Directrices De Conception, il n'y a vraiment pas de définir convention pour les variables de membre privées, sauf que l'on ne devrait pas utiliser la notation hongroise et on ne doit pas mettre en majuscule la première lettre du nom de la variable (utilisation de Chameau boîtier). Il y a des citations dans le livre qui prennent en charge vos deux exemples, ainsi que de ne pas utiliser n'importe quel préfixe à tous.

    Personnellement, je préfère le "m_" préfixe.

    InformationsquelleAutor AJ.
  6. 6

    Orientation générale de Microsoft ici:

    http://msdn.microsoft.com/en-us/library/ms229002.aspx

    Automatique de propriétés en C# sont grands et j'utilise alors quand je peux, mais il y a des cas où ils ne travaillent pas pour moi comme quand on fait le type ou la valeur de vérifier sur une méthode de jeu.

    En général: l'utilisation de chameau, de caissons et de ne pas le préfixe de votre nom avec quelque chose comme le trait de soulignement ou un type de préfixe.

    public int Age {get; set;}

    ou

    private int age;
public int Age
{
    get { return age; }
    set
    {
        if(value < 0)
            throw new InvalidOperationException("Age > 0");
        age = value;
    }
}
    • Pas un fan de lever des exceptions est la propriété de lecture/définition. Mais c'est une autre boîte de pandore 🙂
    • Je suis d'accord et pas quelque chose que j'ai rarement le faire. En plus des fins d'illustration. Agreeed, un autre peut-o-worms.
    • Juste une remarque, ce document dit "Le champ de nommage des lignes directrices s'appliquent à la statique du public et des champs protégés. Interne et privé, les champs ne sont pas couverts par les lignes directrices, et le public ou protégé des champs d'instance ne sont pas autorisés par les membres de conception des lignes directrices." Donc, pas de directives officielles.
    InformationsquelleAutor andleer
  7. 5

    Personnellement, j'ai toujours utilisé votre premier exemple de:

        public class Foo
    {
        private int _i;
        private string _id;
    }

    En fait, c'est ce que l'ensemble de mon équipe. En outre celui que vous avez mentionné m_dVal est connu comme la Notation hongroise, voici la L'Entrée De Wikipedia. La Notation hongroise est fait à l'encontre de nos équipes les normes de codage, donc je ne l'utilise jamais.

    InformationsquelleAutor Alexander Kahoun
  8. 4

    Le mieux est d'utiliser ce qui est déjà utilisée dans le projet. Si vous démarrez un nouveau projet, faites ce qui est le plus souvent utilisé dans l'entreprise.

    • Si vous démarrez une nouvelle entreprise, lance une pièce de monnaie. 🙂
    InformationsquelleAutor ibz
  9. 3

    Je préfère le trait de soulignement comme préfixe pour le privé non const non readonly champs. Pourquoi? Raisons:
    1. Tout simplement à la recherche sur la variable I peut faire la distinction entre le champ & local/paramètre variable. L'utilisation de "ce." pour tous les champs n'est pas une option - ses plus.
    2. Il existe une ambiguïté entre le paramètre et du terrain:

    class Foo
{
  private int id;
  public Foo(int id)
  {
    id = id; //Will compile and work fine. But field will not be initialized.
  }
}
    • Ce scénario va générer un message d'avertissement si.
    • Combien de places d'appliquer un 0 avertissement dans les versions de la politique ?
    • vous verrez une ligne sinueuse mais dans la plupart des éditeurs. Donc, vous allez obtenir ce repère visuel.
    InformationsquelleAutor Aleksei
  10. 2

    Je préfère ne pas utiliser n'importe quel préfixe à tous pour les variables de membre. Pour celles qui sont déclarées en dehors de la méthode, j'utilise "ce.memberVariableName" pour les distinguer de celles qui sont déclarées à l'intérieur de la méthode.

    • De même, je l'utilise en faveur de préfixer avec _
    InformationsquelleAutor cyclo
  11. 1

    J'ai tendance à aller avec le premier de la convention, d'un simple trait de soulignement. Je n'ai pas spécifier le type dans le nom, parce que j'ai Intellisense pour me dire ce que c'est (je sais, ça peut être une béquille).

    Préférable de vérifier avec vos collègues de travail ou d'un projet coéquipiers et simplement décider sur une convention, certains d'entre eux sont une sorte de arbitraire.

    InformationsquelleAutor Jon Dewees
  12. 0

    En C++ identificateurs commençant par _ sont considéré comme une mauvaise pratique, ils devraient être de gauche pour un usage interne. Je pense que c'est pourquoi les préfixant d'un nom de variable avec _ est parfois considéré comme une mauvaise pratique en C# ainsi... même si il n'ya aucune raison pourquoi vous ne pouvez pas le faire, car tous les de la .NET internes sont encapsulées correctement, contrairement au C/C++ bibliothèques standard.

    • En C++, j'aime l' _ comme un suffixe pour les variables de membre (évitant ainsi l'usage interne de l'émission)
    • Ouais, c'est interdit par les normes. J'utilise "m", avec pas souligne - en dépit de la sagesse conventionnelle (plus facile à lire une fois que vous obtenez sur votre perception de partialité et une chose de moins à confondre les débutants).
    InformationsquelleAutor jheriko