Quand utilisez-vous le mot-clé "ce" ?

Question

J'étais curieux de savoir comment d'autres personnes utilisent le este mot-clé. J'ai tendance à l'utiliser dans les constructeurs, mais je peux aussi l'utiliser dans d'autres méthodes de la classe. Quelques exemples :

Dans un constructeur :

public Light(Vector v)
{
    this.dir = new Vector(v);
}

Ailleurs

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

Answer 1

Je ne veux pas paraître narquois, mais ça n'a pas d'importance.

Sérieusement.

Regardez les choses qui sont importantes : votre projet, votre code, votre travail, votre vie personnelle. Aucun d'entre eux ne verra son succès reposer sur le fait que vous utilisiez ou non le mot-clé "this" pour qualifier l'accès aux champs. Le mot-clé this ne vous aidera pas à expédier vos produits à temps. Il ne réduira pas les bogues, il n'aura pas d'effet notable sur la qualité du code ou la maintenabilité. Il ne vous permettra pas d'obtenir une augmentation de salaire, ni de passer moins de temps au bureau.

C'est vraiment une question de style. Si vous aimez "ceci", alors utilisez-le. Si vous ne l'aimez pas, ne le faites pas. Si vous en avez besoin pour obtenir une sémantique correcte, alors utilisez-le. En réalité, chaque programmeur a un style de programmation qui lui est propre. Ce style reflète les notions de ce programmeur particulier de ce que le "code le plus esthétiquement agréable" devrait ressembler. Par définition, tout autre programmeur qui lit votre code aura un style de programmation différent. Cela signifie qu'il y aura toujours quelque chose que vous avez fait que l'autre personne n'aime pas ou qu'elle aurait fait différemment. À un moment donné, un type va lire votre code et se plaindre de quelque chose.

Je ne m'en ferais pas pour ça. Je m'assurerais simplement que le code est aussi esthétique que possible, selon vos propres goûts. Si vous demandez à 10 programmeurs comment formater le code, vous obtiendrez une quinzaine d'avis différents. Il est préférable de se concentrer sur la façon dont le code est structuré. Les choses sont-elles bien abstraites ? Ai-je choisi des noms significatifs pour les choses ? Y a-t-il beaucoup de duplication de code ? Y a-t-il des moyens de simplifier les choses ? Je pense que le fait d'obtenir ces choses correctement aura le plus grand impact positif sur votre projet, votre code, votre travail et votre vie. Par coïncidence, c'est probablement ce qui fera le moins râler l'autre. Si votre code fonctionne, qu'il est facile à lire et qu'il est bien structuré, l'autre personne ne va pas scruter la façon dont vous initialisez les champs. Il va simplement utiliser votre code, s'émerveiller de sa grandeur, puis passer à autre chose.

Answer 2

Il existe plusieurs usages de este en C#.

1. Pour qualifier les membres cachés par un nom similaire
2. Pour qu'un objet se transmette lui-même comme paramètre à d'autres méthodes
3. Pour qu'un objet se retourne lui-même depuis une méthode
4. Pour déclarer les indexeurs
5. Pour déclarer des méthodes d'extension
6. Pour passer des paramètres entre les constructeurs
7. Pour réaffecter en interne le type de valeur (struct) valeur .
8. Pour invoquer une méthode d'extension sur l'instance courante
9. Pour se transformer en un autre type
10. Pour enchaîner les constructeurs définis dans la même classe

Vous pouvez éviter la première utilisation en n'ayant pas de variables membres et locales avec le même nom dans la portée, par exemple en suivant les conventions de nommage communes et en utilisant des propriétés (cas Pascal) au lieu de champs (cas Camel) pour éviter d'entrer en collision avec des variables locales (également cas Camel). En C# 3.0, les champs peuvent être facilement convertis en propriétés en utilisant la commande propriétés auto-implémentées .

Answer 3

Je ne l'utilise que lorsque c'est absolument nécessaire, c'est-à-dire lorsqu'une variable en cache une autre. Comme ici :

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

Ou, comme le souligne Ryan Fox, lorsque vous devez le passer en paramètre. (Les variables locales ont la priorité sur les variables membres)

Answer 4

Personnellement, j'essaie de toujours utiliser este lorsqu'il s'agit de variables membres. Cela permet de clarifier le code et de le rendre plus lisible. Même s'il n'y a aucune ambiguïté, quelqu'un qui lit mon code pour la première fois ne le sait pas, mais s'il voit este Utilisés de manière cohérente, ils sauront s'il s'agit d'une variable membre ou non.

Answer 5

Je n'arrive pas à croire toutes les personnes qui disent que l'utiliser systématiquement est une "meilleure pratique" et autres.

Utilisez "ce" lorsqu'il y a ambiguïté, comme dans L'exemple de Corey ou lorsque vous devez passer l'objet comme un paramètre, comme dans L'exemple de Ryan . Il n'y a aucune raison de l'utiliser autrement, car le fait de pouvoir résoudre une variable sur la base de la chaîne de portée devrait être suffisamment clair pour qu'il ne soit pas nécessaire de qualifier les variables avec elle.

EDIT : La documentation C# sur "this" indique une autre utilisation, en plus des deux que j'ai mentionnées, pour le mot clé "this" - pour déclarer les indexeurs

EDIT : @Juan : Huh, je ne vois pas d'incohérence dans mes déclarations - il y a 3 cas où j'utiliserais le mot-clé "this" (comme indiqué dans la documentation C#), et ce sont les cas où l'on a effectivement Necesito il. Coller "this" devant des variables dans un constructeur alors qu'il n'y a pas d'ombrage est simplement une perte de frappe et une perte de temps pour moi en le lisant, cela n'apporte aucun bénéfice.