Pourquoi Microsoft a-t-il fait en sorte que les paramètres, les variables locales et les champs privés aient la même convention de dénomination de nom?

J'ai posé cette question il y a un certain temps: comment nommez-vous vos variables privées en C #?

Dans l'une des réponses, j'ai été pointé vers la page MSDN de Microsoft qui montre que les variables / champs privés doivent être nommés comme ceci:

private int myInteger;

Mais un paramètre serait:

void SomeMethod(int myInteger)

et une variable locale serait comme ceci:

int myInteger;

Donc, quand vous les référencez comme ça

myInteger = 10;

vous n'avez aucun moyen de savoir de qui vous parlez.

Je commence maintenant un nouveau projet et l'un de mes collègues me demande pourquoi nous ne faisons rien pour différencier au moins certains d'entre eux.

Je me demande la même chose. Pourquoi la norme de Microsoft n'a-t-elle pas conservé ces différences?

Les conventions de nommage d'origine avaient un préfixe m_ pour les membres de la classe, cela a été réduit à un simple soulignement. Vous verrez beaucoup d'anciens codes C # Microsoft utilisant un préfixe de soulignement. Cependant, j'ai entendu une fois dans un Tech Ed qu'un soulignement de premier plan n'est pas conforme à CLS. Je suppose que c'est la raison pour laquelle ils sont passés au régime plus simple à nom unique. Autrefois (pas sûr maintenant), les noms insensibles à la casse de VB.Net n'étaient pas non plus conformes CLS.

Pour ce que ça vaut, j'utilise toujours le soulignement de tête pour les membres de la classe. Même si vous pouvez lever l'ambiguïté en utilisant this (this.name par opposition à name), les bogues continuent de passer.

Vous n'êtes pas obligé de faire tout ce que MS vous dit de faire.

localet les parametervariables sont nommées de la même manière car leur portée est la même

En ce qui concerne les variables privées, il existe différentes opinions à ce sujet. J'ai toujours utilisé les normes trouvées ici , qui spécifient d'utiliser un leader _avant les variables privées, bien que l'auteur dise que _c'est un peu controversé et que Microsoft le recommande.

Wikipedia indique qu'en C et C ++

Les noms commençant par un double trait de soulignement ou un trait de soulignement et une lettre majuscule sont réservés à l'implémentation (compilateur, bibliothèque standard) et ne doivent pas être utilisés (par exemple __reserved ou _Reserved).

c'est peut-être la raison pour laquelle Microsoft a recommandé de ne pas le faire, bien qu'il soit assez bien connu que de nombreux développeurs Microsoft utilisent de toute façon un _préfixe pour leurs variables privées.

Je ne peux pas vous dire avec certitude pourquoi ils ne les ont pas différenciés. Il est probable que personne ne peut le faire à moins que quelqu'un qui a participé à la création des normes ne voie cette question.

Beaucoup de gens créent leurs propres conventions en préfixant les variables d'instance avec _ou m_, mais je ne pense vraiment pas que cela soit important. Vous pouvez en déduire beaucoup du contexte et les IDE de nos jours sont assez intelligents pour vous aider. Visual Studio avec l'addon ReSharper, par exemple, vous montrera des variables locales et des variables d'instance de différentes couleurs.

S'il importe vraiment que vous différenciez les deux étendues, vous pouvez utiliser le this.préfixe pour faire référence à la variable d'instance:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Sans aucun autre plugin, Visual Studio vous aidera par défaut avec Intellisense:

(Le pop-up peut toujours être stylé par ReSharper là-bas, mais ReSharper n'ajoute rien aux fonctionnalités d'Intellisense intégré, donc bien que celui d'origine soit un peu différent, il aura toujours les deux options là-dedans. )

Vous pouvez également utiliser des outils d'analyse de code tels que FxCop et StyleCop pour vous aider à détecter les problèmes potentiels liés à la dénomination et à la portée des variables.

Pourquoi la norme de Microsoft n'a-t-elle pas conservé ces différences?

Les gens de Microsoft ont écrit un livre intitulé Framework Design Guidelines qui expliquait un certain nombre de conventions, y compris pourquoi certaines choses étaient enfermées dans un chameau et d'autres dans un boîtier pascal .

Modifier (en ajoutant des détails du livre):

Dans le livre, ils mentionnent avoir fait des études d'utilisabilité, ainsi que certaines des leçons tirées de l'acquisition du groupe Turbo Pascal. De plus, bien que tous les langages ne soient pas sensibles à la casse (tels que VB), d'autres le sont (tels que C #), donc l'un doit être cohérent dans son nom. On ne peut pas dépendre des différences dans le cas seul pour distinguer les articles. Si l'on s'en tient aux conventions utilisées par le reste du framework, cela entraînera moins de confusion chez les développeurs.

Chapitre 3, Consignes de dénomination.
La section 3.1 est consacrée aux conventions de capitalisation.

camelCasingest pour les noms de paramètres.
PascalCasingest pour les noms d'espace, de type et de membre. Dans le cas où des acronymes de 2 lettres font partie du nom, conservez-les en majuscules, par exemple IOStream.

La section 3.5 couvre les noms des classes, des structures et des interfaces.
La section 3.6 couvre les noms des membres de type.
La section 3.7 couvre les paramètres de dénomination.

Parce qu'ils sont assez faciles à distinguer car ils dépendent du contexte dans lequel ils sont écrits.

Par exemple, avez-vous déjà utilisé un paramètre comme variable membre? Ou une variable locale comme paramètre? Que diriez-vous d'une variable membre en tant que variable locale?

• Toutes les variables membres sont dans le "corps" d'une classe. Je n'achète vraiment pas l'argument selon lequel vous devez préfixer le membre lorsque vous pouvez l'utiliser thispour le distinguer d'une variable locale avec un nom similaire, sinon ce n'est pas nécessaire.

• Une variable locale est également définie uniquement dans la portée d'une méthode ou dans une portée de bloc de code.

• Un paramètre est toujours défini dans la signature de la méthode.

Si vous confondez ou mélangez tous ces types de variables, vous devriez vraiment penser davantage à la conception de votre code pour le rendre plus lisible ou détectable. Donnez-leur des noms meilleurs et plus auto-descriptifs que myInteger.

Je ne peux pas répondre à votre question sur les normes de Microsoft. Si vous voulez une norme pour différencier ces choses, l'utilisation standard I pour les paramètres PL / SQL est préfixant le nom du paramètre avec in_, out_, io_, pour les paramètres entrée, de sortie, et en OUT-. Les variables locales à une fonction sont précédées d'un a v_.

La plupart des entreprises que je connais ont des normes de codage qui spécifient un trait de soulignement ou la lettre minuscule m (pour "membre" je suppose) comme préfixe pour leurs variables de membre.

Donc

_varName

ou

mVarName

Tout comme d'autres l'ont fait remarquer, vous pouvez généralement savoir lequel est le champ d'application de l'élément. En fait, vous ne pouvez pas avoir le paramètre et la variable locale dans la même portée et si vous voulez la variable privée, utilisez simplement this.myInteger. Je ne pense donc pas que Microsoft s'en préoccupe trop, car vous pouvez facilement les différencier si vous le souhaitez.

Mais cela étant dit, je suis un peu surpris que personne ne l'ait encore dit, mais oubliez Microsoft et leurs conventions de dénomination (enfin quelqu'un aurait pu le dire maintenant car j'ai dû courir à une réunion et laisser cela ouvert sans le soumettre) il). La notation hongroise était également une convention de dénomination commencée chez Microsoft (ou était-ce Xerox? Je ne me souviens jamais quand Simonyi l'a inventée). Je ne peux penser à personne que je connaisse qui ne maudisse pas le nom de la notation hongroise à ce jour. Nous sommes devenus tellement ennuyés à l'endroit que j'ai travaillé que nous avons trouvé notre propre norme que nous avons utilisée en interne. Cela avait plus de sens pour nous et accélérait un peu notre travail (c'était en fait assez proche de ce que Microsoft suggère maintenant, mais tout était le cas pascal à l'exception des variables privées).

Cela étant dit, la nouvelle norme utilisée par Microsoft (le mélange de la camel case et de la pascal case) n'est pas trop mauvaise. Mais si vous et vos collègues ne l'aimez pas, créez votre propre ensemble de normes (collectivement, c'est mieux). Cela dépend bien sûr du fait que votre entreprise dispose déjà d'un ensemble de normes. S'ils le font, respectez-les. Sinon, trouvez ce qui fonctionne pour vous et vos collègues. Reste juste logique.

Depuis qu'Aaronaught a demandé des citations sur Charles Simonyi et la notation hongroise: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Les deux derniers ne sont que des exemples de notation hongroise et le lien ootips n'est que quelques citations concernant certaines opinions sur le sujet. Notez qu'il existe également un système de notation hongroise mais qui, à ma connaissance, est également devenu populaire auprès des programmeurs Microsoft (bien que contrairement à Simonyi pour la variante des applications, je ne sais pas qui).