Pourquoi StyleCop recommande-t-il de préfixer les appels de méthode ou de propriété avec "this"?

Question

J'ai essayé de suivre StyleCop les lignes directrices d'un projet, pour voir si le code résultant est mieux à la fin. La plupart des règles sont raisonnables ou une question d'opinion sur la norme de codage, mais il y a une règle qui me énigmes, parce que je n'ai pas vu quelqu'un d'autre de le recommander, et parce que je ne vois pas un avantage évident pour elle:

SA1101: L'appel de {nom de méthode ou propriété} doit commencer par la " cela.' préfixe pour indiquer que l'élément est un membre de la classe.

Sur le revers de la médaille, le code est nettement plus détaillé de cette façon, alors, quels sont les avantages de suivre cette règle? Est-ce que quelqu'suivre cette règle?

Answer 1

Je ne suis pas vraiment ces conseils, sauf si je suis dans les scénarios dont vous avez besoin:

• il y a une ambiguïté réelle - cela touche principalement les constructeurs ( this.name = name; ) ou des choses comme Equals ( return this.id == other.id; )
• vous voulez passer une référence à l'instance actuelle
• vous voulez appeler une méthode d'extension sur l'instance actuelle

Autre que cela, je considère ce fouillis. Donc, je désactive la règle.

Answer 2

Cela peut rendre le code plus clair en un coup d'œil. Lorsque vous utilisez this , il est plus facile de:

• Indiquez les membres statiques et les membres d'instance à part. (Et distinguer les méthodes d'instance des délégués.)
• Distinguez les membres d'instance des variables et paramètres locaux (sans utiliser de convention de dénomination).

Answer 3

Je pense que cet article explique un peu

http://blogs.msdn.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

...un jeune et brillant développeur chez Microsoft (ok, c'était moi) a décidé de prendre sur lui d'écrire un petit outil permettant de détecter les écarts par rapport au C# style utilisé au sein de son équipe. StyleCop est né. Au cours des prochaines années, nous nous sommes réunis tous les C# les directives de style que nous avons pu trouver à partir de différentes équipes au sein de Microsoft, et pris toutes les meilleures pratiques qui sont communs à ces styles. Ils ont constitué la première série de StyleCop règles. L'une des premières règles qui sortait de cet effort a été l'utilisation de ce préfixe pour appeler les membres de la classe, et la suppression de tout caractère de soulignement préfixes de noms de domaine. C# style a officiellement cultivé en dehors de ses vieux C++ tribu.

Answer 4

this.This 
this.Does 
this.Not 
this.Add 
this.Clarity 
this.Nor 
this.Does 
this.This 
this.Add 
this.Maintainability 
this.To 
this.Code

L'utilisation de "cette.", lors de l'utilisation excessive ou forcée de style exigence, n'est rien de plus qu'un stratagème utilisé sous le prétexte qu'il est < 1% des développeurs qui ne comprends vraiment pas de code ou de ce qu'ils font, et il est douloureux pour les 99% qui veulent écrire facilement lisible et maintenable code.

Dès que vous commencez à taper, Intellisence liste le contenu disponible dans le champ d'application de l'endroit où vous tapez, "cette." n'est pas nécessaire d'exposer les membres de la classe, et, sauf si vous êtes complètement paumé à ce que vous êtes codant pour vous devriez être en mesure de trouver facilement l'élément dont vous avez besoin.

Même si vous êtes complètement paumé, utiliser "ce." faire allusion à ce qui est disponible, mais ne le laissez pas dans le code. Il y a aussi un tas d'add-ons comme Resharper qui aident à apporter de la clarté à la portée et à exposer le contenu des objets de manière plus efficace. Il est préférable d'apprendre à utiliser les outils fournis pour vous, alors à développer une mauvaise habitude qui est détesté par un grand nombre de vos collègues.

Tout développeur qui n'est pas inhérente à comprendre la portée de la statique, des locaux, de la classe ou de contenu global ne doit pas s'appuyer sur des "indices" pour préciser la portée. "cette." est pire que de la notation hongroise au moins notation hongroise fourni une idée sur le type de la variable est le référencement et sert de certains avantages. Je verrais plutôt "_" ou "m" est utilisé pour désigner le champ classe de membres que de voir "ce." partout.

Je n'ai jamais eu de problème, ni vu un problème avec un autre développeur qui à plusieurs reprises des combats avec le code de la portée ou de l'écriture du code qui est toujours buggé parce que de ne pas utiliser "ce." explicitement. Il est injustifié de peur que "ça". prévient futur code de bugs et est souvent l'argument utilisé là où l'ignorance de la valeur.

Les codeurs à croître avec l'expérience, "cette.", c'est comme demander à quelqu'un de mettre des roues de formation sur leur vélo à l'âge adulte, car c'est ce qu'ils avaient à utiliser pour apprendre à faire du vélo. Et de l'adulte peut tomber un vélo de 1 pour 1 000 fois qu'ils les obtenir sur elle, mais c'est pas une raison pour forcer à utiliser des roues de formation.

"cette." devrait être banni de la définition du langage C#, malheureusement, il n'existe qu'une seule raison pour qu'il l'aide, et c'est pour résoudre l'ambiguïté, ce qui pourrait aussi être facilement résolu par une meilleure code de pratiques.

Answer 5

Notez que le compilateur ne se soucie pas si vous préfixe références avec le this ou pas (sauf si il y a une collision de nom avec une variable locale et d'un terrain ou que vous souhaitez appeler une méthode d'extension sur l'instance en cours.)

C'est à votre style. Personnellement, j'ai supprimer this. de code car je pense qu'il diminue le rapport signal sur bruit.

Tout simplement parce que Microsoft utilise ce style en interne ne signifie pas que vous devez. StyleCop semble être un MS-outil interne entrés dans le domaine public. Je suis tout à fait d'adhérer aux conventions Microsoft autour de publique de choses, comme:

• tapez les noms sont en PascalCase
• les noms de paramètres sont en camelCase
• l'interface doit être préfixé par la lettre I
• utiliser des noms singuliers pour les enums, sauf lorsqu'ils sont à la [Drapeaux]

...mais ce qui se passe dans le privé, les domaines de votre code est bien privé. Faire tout ce que votre équipe est d'accord sur.

La cohérence est également important. Il réduit la charge cognitive lors de la lecture de code, surtout si le code de style est, comme vous vous y attendez. Mais même lorsqu'il s'agit d'un étranger style de codage, si c'est cohérent, alors il ne faudra pas longtemps pour s'habituer à elle. Utiliser des outils comme ReSharper et StyleCop pour s'assurer de la cohérence là où vous pensez que c'est important.

À l'aide de .NET Réflecteur suggère que Microsoft n'est pas grande à adhérer à la StyleCop les normes de codage de la BCL, de toute façon.