Pourquoi StyleCop recommande-t-il de préfixer les appels de méthode ou de propriété avec "this"?
J'ai essayé de suivre les directives de StyleCop sur un projet, pour voir si le code résultant était finalement meilleur. 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 laisse perplexe, parce que je n'ai vu personne d'autre le recommander, et parce que je ne vois aucun avantage clair à cela:
SA1101: L'appel à {méthode ou nom de propriété} doit commencer par le préfixe 'this.' Pour indiquer que l'élément est membre de la classe.
À la baisse, le code est clairement plus détaillé de cette façon, alors quels sont les avantages de suivre cette règle? Est-ce que quelqu'un ici suit cette règle?
Cela peut rendre le code plus clair en un coup d'œil. Lorsque vous utilisez this, il est plus facile de:
- Distinguez les membres statiques et d'instance. (Et distinguez les méthodes d'instance des délégués.)
- Distinguer les membres d'instance des variables et paramètres locaux (sans utiliser de convention de dénomination).
Je ne suis pas vraiment ce guide, sauf si je suis dans les scénarios dont vous avez besoin:
- il y a une ambiguïté réelle - principalement cela affecte les constructeurs (
this.name = name;) ou des choses commeEquals(return this.id == other.id;) - vous voulez passer une référence à l'instance actuelle
- vous souhaitez appeler une méthode d'extension sur l'instance actuelle
A part ça, je considère cet encombrement. J'ai donc désactivé la règle.
Je pense que cet article l'explique un peu
http://blogs.msdn.Microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx
... un brillant jeune développeur de Microsoft (ok, c'était moi) a décidé de prendre sur lui d'écrire un petit outil qui pourrait détecter les écarts par rapport au style C # utilisé au sein de son équipe. StyleCop était né. Au cours des prochaines années, nous avons rassemblé toutes les directives de style C # que nous pouvions trouver auprès des différentes équipes de Microsoft, et avons sélectionné toutes les meilleures pratiques communes à ces styles. Celles-ci ont formé le premier ensemble de règles StyleCop. L'une des premières règles issues de cet effort a été l'utilisation du préfixe this pour appeler les membres de la classe et la suppression de tous les préfixes de soulignement de noms de champs. Le style C # s'était officiellement séparé de son ancienne tribu C++.
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 "this.", Lorsqu'il est utilisé de manière excessive ou une exigence de style forcé, n'est rien de plus qu'un artifice utilisé sous prétexte qu'il y a <1% de développeurs qui ne comprennent vraiment pas le code ou ce qu'ils font, et le font pénible pour 99% qui souhaitent écrire du code facilement lisible et maintenable.
Dès que vous commencez à taper, Intellisence répertorie le contenu disponible dans la portée de l'endroit où vous tapez, "ceci". n'est pas nécessaire d'exposer les membres de la classe, et à moins que vous ne sachiez complètement ce que vous codez, vous devriez pouvoir trouver facilement l'élément dont vous avez besoin.
Même si vous êtes complètement désemparé, utilisez "ceci". pour indiquer ce qui est disponible, mais ne le laissez pas dans le code. Il existe également une multitude d'add-ons comme Resharper qui aident à clarifier la portée et à exposer le contenu des objets plus efficacement. Il vaut mieux apprendre à utiliser les outils mis à votre disposition puis développer une mauvaise habitude détestée par un grand nombre de vos collègues.
Tout développeur qui ne comprend pas intrinsèquement la portée du contenu statique, local, de classe ou global ne doit pas s'appuyer sur des "conseils" pour indiquer la portée. "ce." est pire que la notation hongroise, car au moins la notation hongroise a fourni une idée du type auquel la variable fait référence et présente certains avantages. Je préfère voir "_" ou "m" utilisé pour désigner les membres du champ de classe, puis pour voir "ceci". partout.
Je n'ai jamais eu de problème, ni vu de problème avec un collègue développeur qui se bat à plusieurs reprises avec la portée du code ou écrit du code qui est toujours bogué car je n'utilise pas "this". explicitement. C'est une crainte injustifiée que "ceci". empêche les futurs bogues de code et est souvent l'argument utilisé lorsque l'ignorance est valorisée.
Les codeurs grandissent avec l'expérience, "ceci". c'est comme demander à quelqu'un de mettre des roues d'entraînement sur son vélo en tant qu'adulte parce que c'est ce qu'il a d'abord dû utiliser pour apprendre à faire du vélo. Et un adulte peut tomber d'un vélo 1 fois sur 1 000, mais ce n'est pas une raison pour le forcer à utiliser des roues d'entraînement.
"ce." devrait être banni de la définition du langage pour C #, malheureusement, il n'y a qu'une seule raison de l'utiliser, c'est de résoudre l'ambiguïté, qui pourrait également être facilement résolue par de meilleures pratiques de code.
Notez que le compilateur ne se soucie pas de savoir si vous préfixez les références avec this ou non (sauf s'il y a une collision de nom avec une variable locale et un champ ou si vous voulez appeler une méthode d'extension sur l'instance actuelle.)
Cela dépend de votre style. Personnellement, je supprime this. du code car je pense que cela diminue le rapport signal/bruit.
Ce n'est pas parce que Microsoft utilise ce style en interne que vous devez le faire. StyleCop semble être un outil interne à MS rendu public. Je suis tout à fait d'accord avec les conventions de Microsoft concernant les choses publiques, telles que:
- les noms de type sont en PascalCase
- les noms des paramètres sont dans camelCase
- les interfaces doivent être préfixées de la lettre I
- utiliser des noms singuliers pour les énumérations, sauf lorsqu'ils sont [Drapeaux]
... mais ce qui se passe dans les domaines privés de votre code est, enfin, privé. Faites ce que votre équipe accepte.
La cohérence est également importante. Il réduit la charge cognitive lors de la lecture de code, surtout si le style de code est tel que vous vous y attendez. Mais même lorsqu'il s'agit d'un style de codage étranger, s'il est cohérent, il ne faudra pas longtemps pour s'y habituer. Utilisez des outils comme ReSharper et StyleCop pour assurer la cohérence là où vous pensez que c'est important.
L'utilisation de .NET Reflector suggère que Microsoft n'est pas si bon à respecter les normes de codage StyleCop dans la BCL de toute façon.
Quelques raisons de base pour utiliser this (et par coïncidence, je préfère toujours les valeurs de classe avec le nom de la classe dont elles font également partie - même au sein de la classe elle-même).
1) Clarté. Vous savez à cet instant quelles variables vous avez déclarées dans la définition de classe et que vous avez déclarées comme locales, paramètres et ainsi de suite. Dans deux ans, vous ne le saurez pas et vous partirez pour un merveilleux voyage de redécouverte qui est absolument inutile et inutile si vous spécifiez le parent à l'avance. Quelqu'un d'autre travaillant sur votre code n'a aucune idée dès le départ et bénéficie donc instantanément.
2) Intellisense. Si vous tapez "ceci". vous obtenez tous les membres et propriétés spécifiques à l'instance dans l'aide. Cela rend la recherche des choses beaucoup plus facile, surtout si vous gérez le code de quelqu'un d'autre ou le code que vous n'avez pas regardé depuis quelques années. Il vous aide également à éviter les erreurs causées par des idées fausses sur les variables et les méthodes déclarées où et comment. Il peut vous aider à découvrir des erreurs qui autrement n'apparaîtraient pas avant que le compilateur ne s'étouffe sur votre code.
3) Certes, vous pouvez obtenir le même effet en utilisant des préfixes et d'autres techniques, mais cela soulève la question de savoir pourquoi vous inventeriez un mécanisme pour gérer un problème alors qu'il existe un mécanisme pour le faire intégré dans le langage qui est réellement pris en charge par le IDE? Si vous tapez, même en partie, cela réduira également votre taux d'erreur en ne vous forçant pas à retirer vos doigts de la position initiale pour accéder à la touche de soulignement.
Je vois beaucoup de jeunes programmeurs qui font une grosse affaire du temps qu'ils économiseront en ne tapant pas un caractère ou deux. La plupart de votre temps sera consacré au débogage, pas au codage. Ne vous inquiétez pas tellement de votre vitesse de frappe. Inquiétez-vous davantage de la rapidité avec laquelle vous pouvez comprendre ce qui se passe dans le code. Si vous enregistrez un total de cinq minutes de codage et gagnez en dépensant dix minutes de débogage supplémentaires, vous vous êtes ralenti, peu importe la vitesse à laquelle vous regardez comme si vous alliez.
Je le suis, car je pense que c'est vraiment pratique de pouvoir distinguer l'accès aux membres statiques et d'instance à première vue.
Et bien sûr, je dois l'utiliser dans mes constructeurs, car je donne normalement aux paramètres du constructeur les mêmes noms que le champ auquel leurs valeurs sont affectées. J'ai donc besoin de "ceci" pour accéder aux champs.
De plus, il est possible de dupliquer les noms de variables dans une fonction, donc l'utilisation de "ceci" peut la rendre plus claire.
class foo {
private string aString;
public void SetString(string aString){
//this.aString refers to the class field
//aString refers to the method parameter
this.aString = aString;
}
}
Je le suis principalement pour intellisense raisons. C'est tellement agréable de taper this. et obtenir une liste de propriétés, de méthodes, etc.