Souligner ou ne pas souligner, telle est la question

Y a-t-il des problèmes avec le fait de ne pas préfixer les champs privés avec un trait de soulignement en C # si la version binaire va être consommée par d'autres langages du framework? Par exemple, puisque C # est sensible à la casse, vous pouvez appeler un champ "foo" et la propriété publique "Foo" et cela fonctionne très bien.

Cela aurait-il un effet sur un langage insensible à la casse tel que VB.NET, y aura-t-il des problèmes de conformité CLS (ou autres) si les noms ne peuvent être distingués que par la casse?

Cela n'aura aucun effet.

Une partie des recommandations pour écrire des bibliothèques conformes CLS est de NE PAS avoir deux entités publiques / protégées qui ne diffèrent que par cas, par exemple vous ne devriez PAS avoir

public void foo() {...}

et

public void Foo() {...}

ce que vous décrivez n'est pas un problème car l'élément privé n'est pas disponible pour l'utilisateur de la bibliothèque

MISE À JOUR IMPORTANTE (12 avril 2016):

Il a été porté à notre attention que le standard interne de l'équipe .NET CoreFX insiste sur l'utilisation de la notation de soulignement sans donner aucune idée de pourquoi. Cependant , si nous regardons de près la règle n ° 3 , il devient évident qu'il existe un système de _, t_, s_préfixes qui suggère pourquoi _a été choisi en premier lieu.

3. Nous utilisons _camelCasepour les champs internes et privés et utilisons en lecture seule lorsque cela est possible. Préfixez les champs d'instance avec _, les champs statiques avec s_et les champs statiques de thread avec t_. Lorsqu'il est utilisé sur des champs statiques, readonlydoit venir après static(c'est-à-dire static readonlypas readonly static).
4. Nous évitons à this.moins que cela ne soit absolument nécessaire.

Donc, si vous êtes juste comme l'équipe .NET CoreFX travaillant sur un code de niveau système multithread critique pour les performances , il est FORTEMENT SUGGÉRÉ que vous:

• respecter leurs normes de codage et
• utilisez la notation de soulignement et
• ne lisez plus cette réponse

Sinon, lisez la suite ...

LA RÉPONSE ORIGINALE:

Mettons-nous d'abord d'accord sur ce dont nous parlons. La question est de savoir comment nous accédons aux membres d'instance à partir de méthodes non statiques et de constructeurs d'une classe / sous-classes si les modificateurs de visibilité le permettent.

Notation de soulignement

• vous suggère d'utiliser le préfixe "_" dans les noms des champs privés
• il dit aussi que vous ne devriez jamais utiliser "this" sauf si c'est absolument nécessaire

Cette notation

• suggère de toujours utiliser «ceci». pour accéder à n'importe quel membre de l'instance

Pourquoi cette notation existe-t-elle?

Parce que c'est comme ça que tu

• distinguer un paramètre d'un champ lorsqu'ils partagent le même nom
• assurez-vous que vous travaillez dans le contexte de l'instance actuelle

Exemple

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Pourquoi la notation de soulignement existe-t-elle?

Certaines personnes n'aiment pas taper "ceci", mais elles ont toujours besoin d'un moyen de distinguer un champ et un paramètre, elles ont donc accepté d'utiliser "_" devant un champ

Exemple

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

On peut penser que c'est juste une question de goût personnel et que les deux manières sont également bonnes / mauvaises. Cependant, il y a certains aspects où cette notation bat la notation de soulignement:

Clarté

• la notation de soulignement encombre les noms
• cette notation garde les noms intacts

Charge cognitive

• la notation de soulignement est incohérente, elle vous fait traiter les champs d'une manière spéciale, mais vous ne pouvez pas l'utiliser avec d'autres membres, chaque fois que vous devez vous demander si vous avez besoin d'une propriété ou d'un champ

• cette notation est cohérente, vous n'avez pas à penser, vous utilisez toujours "this" pour désigner un membre

MISE À JOUR: comme cela a été souligné, ce qui suit n'est pas un avantage

Entretien

• La notation de soulignement vous oblige à garder un œil sur la _refactorisation, par exemple en transformant un champ en propriété (supprimer _) ou l'inverse (ajouter _)

• cette notation n'a pas un tel problème

Autocompletion

Lorsque vous avez besoin de voir la liste des membres de l'instance:

• la notation de soulignement ne vous aide pas beaucoup, car lorsque vous tapez "_", la fenêtre contextuelle de saisie semi-automatique vous montre les champs privés et tous les types disponibles à partir des assemblys liés mélangés avec le reste des membres de l'instance
• this-notation vous donne une réponse claire, en tapant "this" tout ce que vous voyez est la liste des membres et rien d'autre

Ambiguïté

Parfois, vous devez gérer le code sans l'aide d'Intellisense. Par exemple, lorsque vous effectuez des révisions de code ou parcourez le code source en ligne.

• La notation de soulignement est ambiguë: lorsque vous voyez Something.SomethingElse, vous ne pouvez pas dire si Something est une classe et SomethingElse est sa propriété statique ... ou peut-être Something est une propriété d'instance actuelle qui a sa propre propriété de SomethingElse

• cette notation est claire: lorsque vous voyez Something.SomethingElse, cela ne peut signifier qu'une classe avec une propriété statique et lorsque vous voyez ceci.Something.SomethingElle vous savez que Something est un membre et SomethingElse est sa propriété

Méthodes d'extension

Vous ne pouvez pas utiliser de méthodes d'extensions sur l'instance elle-même sans utiliser «this».

• la notation de soulignement nécessite que vous n'utilisiez pas "this", mais avec les méthodes d'extension, vous devez
• cette notation vous évite les hésitations, vous utilisez toujours "this", point final.

Prise en charge de Visual Studio

• underscore-notation n'a pas de prise en charge intégrée dans Visual Studio

• this-notation est naturellement pris en charge par Visual Studio:

  1. "Ce." Qualification : préférez que tous les champs non statiques utilisés dans les méthodes non statiques soient précédés this.en C #

Recommandations officielles

Il existe de nombreuses directives officielles qui disent clairement "ne pas utiliser de traits de soulignement", en particulier en C #

• La notation de soulignement vient de C ++ où il s'agit d'une pratique générale qui permet d'éviter les conflits de noms, est également recommandée pour VisualBasic.Net pour surmonter un problème où un champ "valeur" et une propriété "Valeur" ont en fait le même nom, car VisualBasic est insensible à la casse

  1. Noms d'élément déclarés dans Visual Basic
  2. Champs de sauvegarde dans VisualBasic.NET

• cette notation est recommandée pour C # tandis que "_" est explicitement interdit:

  1. ce mot clé en C #
  2. Instructions d'utilisation des champs : n'appliquez pas de préfixe aux noms de champs ou aux noms de champs statiques.
  3. Directives pour les noms: Noms des membres de type : n'utilisez pas de préfixe pour les noms de champ.
  4. Convention de dénomination générale : X N'utilisez PAS de traits de soulignement, de traits d'union ou tout autre caractère non alphanumérique
  5. Règle d'assertion de qualité CA1707 : les identificateurs ne doivent pas contenir de traits de soulignement
  6. L'utilisation de traits de soulignement n'est pas conforme CLS (pour les identifiants publics et protégés)
  7. Convention de dénomination interne des développeurs .NET Framework : n'utilisez pas de préfixe pour les variables membres. Si vous voulez faire la distinction entre les variables locales et membres, vous devez utiliser «this». en C # et "Moi". dans VB.NET.

Extrait du fichier d'aide de Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

CheckId: SA1309

Cause: un nom de champ en C # commence par un trait de soulignement.

Description de la règle:

Une violation de cette règle se produit lorsqu'un nom de champ commence par un trait de soulignement.

Par défaut, StyleCop interdit l'utilisation de traits de soulignement, m_, etc., pour marquer les champs de classe locaux, en faveur du «ceci». préfixe. L'avantage d'utiliser «ceci». est qu'il s'applique également à tous les types d'élément, y compris les méthodes, propriétés, etc., et pas seulement aux champs, rendant tous les appels aux membres de la classe immédiatement reconnaissables, quel que soit l'éditeur utilisé pour afficher le code. Un autre avantage est qu'il crée une différenciation rapide et reconnaissable entre les membres d'instance et les membres statiques, qui ne seront pas préfixés.

Si le nom du champ ou de la variable est destiné à correspondre au nom d'un élément associé à Win32 ou COM et doit donc commencer par un trait de soulignement, placez le champ ou la variable dans une classe NativeMethods spéciale. Une classe NativeMethods est une classe qui contient un nom se terminant par NativeMethods et est conçue comme un espace réservé pour les wrappers Win32 ou COM. StyleCop ignorera cette violation si l'élément est placé dans une classe NativeMethods.

Une description de règle différente indique que la pratique préférée en plus de ce qui précède est de commencer les champs privés avec des lettres minuscules et les champs publics avec des lettres majuscules.

Edit: En guise de suivi, la page du projet de StyleCop se trouve ici: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . La lecture du fichier d'aide donne beaucoup d'informations sur les raisons pour lesquelles ils suggèrent diverses règles stylistiques.

Puisque nous parlons d'un champ privé, cela n'affecte pas un utilisateur de votre classe.

Mais je recommande d'utiliser un trait de soulignement pour le champ privé, car cela peut rendre le code plus facile à comprendre, par exemple:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

Dans notre équipe, nous utilisons toujours un préfixe de soulignement pour les champs privés. Ainsi, en lisant du code, je peux très facilement identifier les champs privés et les distinguer des locaux et des arguments. D'une certaine manière, le trait de soulignement peut être vu comme une version abrégée de «ceci».

Après avoir travaillé dans un environnement qui avait des règles de style très spécifiques et très inutiles depuis, j'ai continué à créer mon propre style. C'est un type que j'ai inversé beaucoup. J'ai finalement décidé que les champs privés seront toujours _field, les variables locales n'auront jamais _ et seront en minuscules, les noms de variables pour les contrôles suivront vaguement la notation hongroise et les paramètres seront généralement camelCase.

Je déteste le this.mot - clé, il ajoute juste trop de bruit de code à mon avis. J'adore Resharper's remove redondant ceci. mot-clé.

Mise à jour de 6 ans: J'analysais les internes de Dictionary<TKey,T>pour une utilisation spécifique de l'accès concurrent et j'ai mal interprété un champ privé comme une variable locale. Les champs privés ne devraient certainement pas avoir la même convention de dénomination que les variables locales. S'il y avait eu un trait de soulignement, cela aurait été incroyablement évident.

J'aime le trait de soulignement, car je peux alors utiliser le nom en minuscules comme paramètres de méthode comme celui-ci:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

J'aime toujours beaucoup utiliser des traits de soulignement devant les champs privés pour la raison mentionnée par Martin, et aussi parce que les champs privés seront ensuite triés dans IntelliSense. Ceci malgré la méchanceté des notations de préfixes hongrois en général.

Cependant, ces derniers temps, je trouve que l'utilisation du préfixe de soulignement pour les membres privés est mal vue, même si je ne sais pas trop pourquoi. Peut-être que quelqu'un d'autre le sait? Est-ce juste le principe du préfixe? Ou y avait-il quelque chose impliqué dans la transformation des noms de types génériques qui obtiennent des traits de soulignement dans les assemblys compilés ou quelque chose?

Recommandation de style Cop ou non, creuser dans le .NET Framework montre une grande utilisation de «_» pour les variables membres. Quoi que recommandent les créateurs de Style Cop, ce n'est pas ce que la majorité des employés de MS utilisent. :) Je m'en tiendrai donc au trait de soulignement. Parce que personnellement, je fais beaucoup moins d'erreurs en utilisant le trait de soulignement que le this (exemple: en utilisant varName = varName au lieu de this.varName = varName, c'est vraiment coincé en moi)

Je pense que dans l'ensemble, les champs au niveau de la classe sont une erreur dans la conception du langage. J'aurais préféré que les propriétés de C # aient leur propre portée locale:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Cela permettrait d'arrêter complètement d'utiliser les champs.

La seule fois où je préfixe un champ privé avec un trait de soulignement, c'est lorsqu'une propriété nécessite un champ de sauvegarde séparé. C'est aussi la seule fois que j'utilise des champs privés. (Et comme je n'utilise jamais de champs protégés, internes ou publics, c'est la seule fois où j'utilise la période des champs.) En ce qui me concerne, si une variable doit avoir une portée de classe, c'est une propriété de la classe.

La notation _fieldName pour les champs privés est si facile à briser . En utilisant «ceci». la notation est impossible à briser. Comment briseriez-vous la notation _? Observer:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

Voilà, je viens de violer votre convention de nommage mais ça compile. Je préférerais avoir une convention de dénomination qui a) n'est pas hongroise et b) explicite. Je suis en faveur de la suppression de la dénomination hongroise et cela qualifie en quelque sorte. Au lieu d'un type d'objet devant le nom de la variable, vous avez son niveau d'accès.

Comparez cela avec Ruby où le nom de la variable @my_number lie le nom dans la portée et est incassable.

edit: Cette réponse est devenue négative. Je m'en fiche, ça reste.

Lorsque vous souhaitez que votre assembly soit conforme CLS, vous pouvez utiliser l'attribut CLSCompliant dans votre fichier assemblyinfo. Le compilateur se plaindra alors lorsque votre code contient des éléments qui ne sont pas conformes à CLS.

Ensuite, lorsque vous avez 2 propriétés qui ne diffèrent que par cas, le compilateur émettra une erreur. Par contre, lorsque vous avez un champ privé et une propriété publique dans la même classe, il n'y aura aucun problème.

(Mais, je préfixe aussi toujours mes membres privés avec un trait de soulignement. Cela m'aide également à préciser quand je lis mon code qu'une certaine variable est un champ de membre).

J'aime utiliser des traits de soulignement devant mes champs privés pour deux raisons. On a déjà été mentionné, les champs se démarquent de leurs propriétés associées dans le code et dans Intellisense. La deuxième raison est que je peux utiliser les mêmes conventions de dénomination que je codifie en VB ou C #.

Il n'y a aucune implication. Lorsque votre code est compilé, tout ce qui est important pour le compilateur est l'espace de noms et la visibilité du champ / propriété. Un trait de soulignement est tout aussi significatif que tout autre caractère lors de la dénomination d'un identifiant. Le vrai truc est d'utiliser une convention que vous et les gens autour de vous comprendrez.