Quelles sont les meilleures pratiques actuelles concernant le mot-clé «this» devant le champ et les méthodes en c #?

À moins qu'il soit nécessaire de faire la différence entre une variable et un champ avec le même nom, je ne mets jamais this.devant un champ ou un accès membre en C #. Je ne vois pas cela comme un m_préfixe qui était commun en C ++, et je pense que si vous avez vraiment besoin de spécifier qu'il s'agit d'un membre, votre classe est trop grande.

Cependant, il y a un certain nombre de personnes dans mon bureau qui sont fortement en désaccord.

Quelles sont les meilleures pratiques actuelles concernant this.?

EDIT: Pour clarifier, je n'utilise jamais m_et n'utilise que this.lorsque c'est absolument nécessaire.

Selon les directives de conception du cadre , lorsque vous vous référez à des domaines publics ou protégés:

NE PAS utiliser un préfixe pour les noms de champ.

Par exemple, m_est un préfixe.

Ainsi, l'exposition publique d'un champ se prête à l'utilisation du thismot clé comme expliqué sur MSDN

Pour qualifier les membres masqués par des noms similaires, par exemple: Copier

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

Lorsque vous faites référence à des champs privés, vous pouvez utiliser le m_si vous le souhaitez. Mais, pour les domaines publics, je recommande de suivre les meilleures pratiques.

Personnellement, je n'aime pas les traits de soulignement dans mes noms de variables. J'essaie aussi d'être cohérent. C'est donc this.name = name;une bonne règle de base pour travailler dans les deux scénarios public / privé.

Dans notre équipe, nous avons adopté la norme d'utilisation du qualificateur d'objet this.ou Me.dans des classes plus grandes pour aider les développeurs juniors à distinguer plus facilement la portée exacte / immédiate d'une variable simplement en la regardant.

Au niveau du code, c'est une affectation totalement inutile, mais elle ne bloque rien car elle génère de toute façon le même code MISL exact. Nous l'avons adopté uniquement parce qu'il répondait à un problème immédiat que nous avons découvert avec certains des juniors. Au-delà de cela, je ne pense pas qu'il soit utile de l'inclure.

StyleCop imposera l'utilisation de this.Donc, si vous considérez cela comme la meilleure pratique (ce que je fais), alors l'utilisation de this.est la meilleure pratique.

Le style que vous adoptez dépend de vous et de vos propres normes de codage, "le meilleur" est celui que vous définissez. Soyez juste cohérent. Son utilisation incohérente ne fait que créer de la confusion.

Mon raisonnement est que l'utilisation this.rappelle le fait que vous faites référence à des propriétés d'instance, donc, par exemple, cela aide à mettre en évidence le fait que vous les mutez (si vous en avez this.x = ...), ce que vous voudrez peut-être savoir. Il met également en évidence le fait que chaque fois que vous voyez this.votre méthode ne peut jamais être statique. L'utilisation d'une convention comme le m_fera également, mais c'est un effort manuel, si vous transformez une m_en statique, ou si vous refactorisez une méthode pour transmettre la valeur de l'extérieur de la classe, vous devez vous rappeler de changer le nom, si vous utilisiez thisalors le compilateur vous forcera à faire le changement.

Simplement utiliser thisest plus facile car si vous vous trompez, votre code ne se compilera pas, si vous l'utilisez m_c'est un effort manuel et vous ne tirez pas parti des outils.

Une des bonnes choses à propos de l'utilisation m_est que dès que vous tapez le petit mintellisense vous donne une liste de toutes vos variables privées, personnellement je pense que c'est un plus en sa faveur; J'irais aussi s_pour la statique privée et c_pour les constantes privées pour des raisons similaires. Il s'agit de la notation hongroise, mais dans le sens où elle a été conçue parce qu'elle ajoute une signification utile au nom de la variable afin que tout autre programmeur puisse en dire des choses à partir de son nom qui peuvent ne pas être totalement évidentes.

Je ne suis certainement pas d'accord avec le fait de n'avoir aucun moyen de faire la distinction entre les variables membres et non membres car elles sont différentes et lorsque je lis du code où les gens ne font pas quelque chose pour le distinguer, il est vraiment plus difficile à lire. L'utilisation this.ressemble à plus de plaque de chaudière que nécessaire. Mais c'est vraiment un goût personnel, si vous codez dans un sens pendant un certain temps, vous finissez par penser que c'est bien et tout le reste est faux. La seule chose qui compte vraiment si le schéma est sain est que tout le monde dans l'équipe est cohérent.

thisest explicite. C'est un signe optique à ne pas manquer.

Je préfère presque toujours le code explicite au code implicite. C'est pourquoi j'utilise thisfréquemment. Je considère que c'est une meilleure pratique.

J'utilise toujours "ceci". Le raisonnement est basé sur deux faits simples:

• La lecture de code est plus difficile que l'écriture de code.
• Vous lisez du code plus souvent que vous n'écrivez du code.

L'utilisation de "ceci" rend tout à fait explicite pour quiconque lit (c'est-à-dire pas seulement l'auteur, mais peut inclure l'auteur dans 6 mois après que les détails de la mise en œuvre ont été complètement oubliés) que oui, c'est un membre de la classe que nous ' re parle ici. "m_" et similaire est juste une convention, et comme toute autre convention, il peut être mal utilisé (ou pas du tout utilisé) - il n'y a rien à appliquer "m _" / etc au moment de la compilation ou au moment de l'exécution. "ceci" est plus fort: vous pouvez mettre "m_" sur une variable locale et le compilateur ne se plaindra pas; vous ne pouvez pas faire ça avec "ça".

Au contraire, je trouve regrettable que l'utilisation de "ceci" n'ait pas été rendue obligatoire dans les spécifications linguistiques.

En prime, lors du débogage, vous pouvez survoler (ou ajouter une veille) le "ceci" et également inspecter tous les autres membres de la classe - des informations précieuses.

Le thismot-clé est utilisé notamment pour distinguer 2 variables qui existent, surtout lorsque vous avez un constructeur ou une méthode avec une variable du même nom mais pouvant avoir le même type.

Exemple:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

Ceci (par exemple this.reason = reason) attribue fondamentalement la valeur des paramètres aux variables de la classe. thisprend essentiellement la classe reasondu bloc de paramètres.

Je me pose également des questions à ce sujet depuis un certain temps. Après avoir fait un codage étendu en javascript, je me suis surpris à utiliser this.plus souvent dans mon code c # (avant cela, je l'ai utilisé presque exclusivement dans des constructeurs ou des méthodes similaires pour éviter toute ambiguïté). Cela rend le code un peu plus clair pour peu d'efforts supplémentaires, de plus vous ne finissez pas par mutiler vos noms de membres de classe avec des préfixes et vous pouvez toujours revenir à utiliser les membres `` à court terme '' lorsque le contexte est clair ou dans des instructions particulièrement complexes. J'ajoute simplement this., lorsque j'ai une méthode plus longue, une liste d'arguments plus longue ou de nombreuses variables locales déclarées et je pense que le code pourrait bénéficier d'une clarté supplémentaire, même s'il est forcé.

Mais personnellement, je déteste absolument le m_style de préfixe, pas tant en raison du hongrois, mais parce que le soulignement est une douleur à taper;) Je ne considère donc pas cela comme une alternative. J'admets qu'il a ses points forts en matière d'intellisense, mais vous pouvez encore faire valoir que si vous ne vous souvenez pas des premières lettres d'une variable membre, votre classe est trop grande.

Je préfère un seul préfixe de soulignement pour les membres de la classe. _someVar;

Pourquoi? Vous savez à première vue que c'est un membre, pas une variable de pile. Juste la commodité en un coup d'œil. Et cela prend moins d'encombrement par rapport au mot-clé "this".

L'utilisation de choses comme le this.préfixe / mot-clé qui ne sont ni nécessaires ni modifient le résultat est toujours subjective. Cependant, je pense que nous pouvons convenir que la plupart d'entre nous veulent différencier les champs des variables locales. Certains utilisent un préfixe de soulignement (que je trouve moche et une sorte de notation hongroise), d'autres utilisent le this.mot - clé. Je fais partie de ces derniers. Il s'agit uniquement de lisibilité et de compréhensibilité. Cela ne me dérange pas de taper un petit plus si c'est plus clair ou plus lisible. Je veux différencier les champs et les variables en un clin d'œil.

Je définis toujours des champs nommés similaires à myFieldet des noms de paramètres et des noms de variables locales également similaires à myField. Pas de soulignements, pas de préfixes. J'utilise thispartout où je fais référence à un domaine. De cette façon, je peux distinguer les champs des variables et arguments locaux sans aucun type de préfixe. Bien sûr, dans un cas comme celui-ci, le thismot clé est requis:

public Person(string firstName)
{
    this.firstName = firstName;
}

Mes propriétés ressemblent donc à ceci (oui, je mets toujours le champ avec la propriété, et pas quelque part sans rapport en haut de mon fichier):

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

Il se lit bien: retournez ce prénom .

EDIT: Ma réponse n'est clairement pas une réponse. Voici donc un montage. Les directives de codage de Microsoft indiquent:

2.6 Désignation

N'utilisez pas de préfixe pour les variables membres ( , m , s_, etc.). Si vous voulez faire la distinction entre les variables locales et les variables membres, vous devez utiliser «this» en C # et «Me» dans VB.NET.

Peut être trouvé à: http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Il semblerait donc qu'au moins de MS, il n'y a pas de ligne directrice claire, bien qu'une autre réponse indique que StyleCop en fait une ligne directrice. Il n'y a aucune autorité sur ces choses, donc je vous suggère de vous faire votre propre opinion, ou dans ce cas de céder à votre équipe. Ce n'est pas si grave.

Ma réponse originale, je suis personnellement d'accord avec vous, mais peut-être qu'un test de compréhension en lecture opposant les deux méthodes serait utile. Sinon, ces choses de style ne sont que de la confusion.

Ma salve à suivre: mon avis est que les gens compliquent inutilement leur style de code, et s'ils doivent indiquer que quelque chose est une variable de niveau de classe, il pourrait y avoir d'autres problèmes structurels graves dans le code, comme la méthode de recette séculaire de placer les variables privées en haut de la classe qui vous obligent à faire défiler constamment de haut en bas.

cela me semble être l'une de ces conventions «ce que c'est» par rapport aux conventions de dénomination «ce qu'il fait». La concision devrait être privilégiée au-dessus d'être explicite. C'est une leçon qui est répétée souvent par les langages dynamiques. Nous n'avons pas besoin de tous les peluches!

cette. peut souvent entraîner des bruits indésirables.

Voici ma solution:

• nom_paramètre_
• variables_locales
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty // Backer
• propriété privée
• _privateProperty // backer