Quand utilisez-vous le mot-clé «this»? [fermé]

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

Chez un constructeur:

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

Autre part

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

Il existe plusieurs utilisations de ce mot clé en C #.

1. Pour qualifier les membres cachés par un nom similaire
2. Pour qu'un objet se passe en paramètre à d'autres méthodes
3. Pour qu'un objet se renvoie d'une méthode
4. Pour déclarer des indexeurs
5. Pour déclarer des méthodes d'extension
6. Pour passer des paramètres entre constructeurs
7. Pour réaffecter en interne une valeur de type (struct) de valeur .
8. Pour appeler une méthode d'extension sur l'instance actuelle
9. Pour se lancer dans un autre type
10. Pour chaîner des 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 dénomination courantes et en utilisant des propriétés (cas Pascal) au lieu de champs (cas chameau) pour éviter d'entrer en collision avec des variables locales (également chameau) Cas). En C # 3.0, les champs peuvent être facilement convertis en propriétés à l'aide de propriétés implémentées automatiquement .

Je ne veux pas que cela semble sarcastique, mais cela 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 n'aura de succès si vous utilisez ou non le mot-clé "this" pour qualifier l'accès aux champs. Ce mot-clé ne vous aidera pas à expédier à temps. Cela ne réduira pas les bogues, cela n'aura aucun effet appréciable sur la qualité ou la maintenabilité du code. Cela ne vous procurera pas d'augmentation ni ne vous permettra de passer moins de temps au bureau.

C'est vraiment juste une question de style. Si vous aimez "ceci", utilisez-le. Si vous ne le faites pas, alors ne le faites pas. Si vous en avez besoin pour obtenir une sémantique correcte, utilisez-la. La vérité est que chaque programmeur a son propre style de programmation. Ce style reflète les notions de ce programmeur particulier de ce à quoi devrait ressembler le "code le plus esthétique". 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 gars n'aime pas ou aurait fait différemment. À un moment donné, un gars va lire votre code et se plaindre de quelque chose.

Je ne m'en inquiéterais pas. Je voudrais juste m'assurer 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 environ 15 opinions différentes. Il vaut mieux se concentrer sur la façon dont le code est factorisé. Les choses sont-elles abstraites correctement? Ai-je choisi des noms significatifs pour les choses? Y a-t-il beaucoup de duplication de code? Existe-t-il des moyens de simplifier les choses? Je pense que le fait de bien faire ces choses aura le plus grand impact positif sur votre projet, votre code, votre travail et votre vie. Par coïncidence, cela fera probablement grogner l'autre gars le moins. Si votre code fonctionne, est facile à lire et est bien pris en compte, l'autre gars ne va pas examiner comment vous initialisez les champs. Il va juste utiliser votre code, s'émerveiller de sa grandeur,

Je ne l'utilise qu'en cas de nécessité absolue, c'est-à-dire lorsqu'une autre variable en observe 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 passer cela en paramètre. (Les variables locales ont priorité sur les variables membres)

Personnellement, j'essaie de toujours utiliser cela lorsque je me réfère à des variables membres. Il aide à clarifier le code et à le rendre plus lisible. Même s'il n'y a pas d'ambiguïté, quelqu'un qui lit mon code pour la première fois ne le sait pas, mais s'il voit que cela est utilisé de manière cohérente, il saura s'il regarde une variable membre ou non.

Je l'utilise chaque fois que je fais référence à une variable d'instance, même si je n'en ai pas besoin. Je pense que cela rend le code plus clair.

Je ne peux pas croire que toutes les personnes qui disent que l’utiliser est toujours une «meilleure pratique», etc.

Utilisez "ceci" en cas d'ambiguïté, comme dans l'exemple de Corey ou lorsque vous devez passer l'objet en paramètre, comme dans l'exemple de Ryan . Il n'y a aucune raison de l'utiliser autrement car être capable de résoudre une variable basée sur la chaîne de portée doit être suffisamment clair pour que les variables qualificatives avec lui ne soient pas nécessaires.

EDIT: La documentation C # sur "ceci" 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 aucune incohérence dans mes déclarations - il y a 3 cas où j'utiliserais le mot-clé "this" (comme documenté dans la documentation C #), et ce sont des moments où vous en avez réellement besoin . Coller "ceci" devant des variables dans un constructeur quand il n'y a pas d'observation est simplement une perte de frappe et une perte de temps en le lisant, cela n'apporte aucun avantage.

Je l'utilise chaque fois que StyleCop me le demande. StyleCop doit être respecté. Oh oui.

Chaque fois que vous avez besoin d'une référence à l'objet actuel.

Un scénario particulièrement pratique est lorsque votre objet appelle une fonction et veut se passer dedans.

Exemple:

void onChange()
{
    screen.draw(this);
}

J'ai tendance à l'utiliser partout aussi, juste pour m'assurer qu'il est clair que ce sont des membres d'instance avec lesquels nous avons affaire.

Je l'utilise partout où il pourrait y avoir une ambiguïté (évidemment). Non seulement l'ambiguïté du compilateur (ce serait nécessaire dans ce cas), mais aussi l'ambiguïté pour quelqu'un qui regarde le code.

Une autre utilisation assez rare du mot clé this est lorsque vous devez appeler une implémentation d'interface explicite à partir de la classe d'implémentation. Voici un exemple artificiel:

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

Voici quand je l'utilise:

• Accès aux méthodes privées depuis la classe (pour différencier)
• Passer l'objet courant à une autre méthode (ou en tant qu'objet émetteur, en cas d'événement)
• Lors de la création de méthodes d'extension: D

Je ne l'utilise pas pour les champs privés car je préfixe les noms de variable de champ privé avec un trait de soulignement (_).

[C ++]

Je suis d'accord avec la brigade "utilisez-le quand vous devez". Décorer le code inutilement avec ce n'est pas une bonne idée car le compilateur ne vous avertira pas lorsque vous oubliez de le faire. Cela introduit une confusion potentielle pour les personnes qui s'attendent à ce que cela soit toujours là, c'est-à-dire qu'elles devront y penser .

Alors, quand l'utiliseriez-vous? Je viens de jeter un œil à du code aléatoire et j'ai trouvé ces exemples (je ne juge pas si ce sont de bonnes choses à faire ou non):

• Passer "vous-même" à une fonction.
• Assigner "vous-même" à un pointeur ou quelque chose comme ça.
• Lancer, c'est-à-dire monter / descendre (sûr ou non), rejeter la constance, etc.
• Le compilateur a imposé la désambiguïsation.

Vous devez toujours l'utiliser, je l'utilise pour différencier les champs et paramètres privés (car nos conventions de dénomination stipulent que nous n'utilisons pas de préfixes pour les noms de membres et de paramètres (et ils sont basés sur des informations trouvées sur Internet, donc je considère qu'un meilleur entrainement))

Je l'utilise lorsque, dans une fonction qui accepte une référence à un objet du même type, je veux préciser parfaitement à quel objet je fais référence, où.

Par exemple

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

(contre)

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

En un coup d'œil à quoi l'AABB fait right()référence? L' thisajoute un peu de clarificateur.

Dans la réponse de Jakub Šturc, son numéro 5 sur la transmission de données entre constructeurs pourrait probablement utiliser une petite explication. C'est dans la surcharge des constructeurs et c'est le seul cas où l'utilisation de thisest obligatoire. Dans l'exemple suivant, nous pouvons appeler le constructeur paramétré à partir du constructeur sans paramètre avec un paramètre par défaut.

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

J'ai trouvé que c'était une fonctionnalité particulièrement utile à l'occasion.

J'ai pris l'habitude de l'utiliser librement dans Visual C ++, car cela déclencherait ceux d'IntelliSense. J'appuie sur la touche «>», et je suis paresseux. (et sujet aux fautes de frappe)

Mais j'ai continué à l'utiliser, car je trouve pratique de voir que j'appelle une fonction membre plutôt qu'une fonction globale.

J'ai tendance à souligner les champs avec _, donc je n'ai jamais vraiment besoin de l'utiliser. De plus, R # a tendance à les refactoriser de toute façon ...

Je assez bien utiliser que ce lorsque vous faites référence une propriété de type à l' intérieur du même type. Comme un autre utilisateur mentionné, je souligne aussi les champs locaux pour qu'ils soient visibles sans avoir besoin ce .

Je l'utilise uniquement lorsque cela est nécessaire, sauf pour les opérations symétriques qui, en raison du polymorphisme à argument unique, doivent être mises dans les méthodes d'un côté:

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

[C ++]

ceci est utilisé dans l'opérateur d'affectation où la plupart du temps vous devez vérifier et éviter des choses étranges (involontaires, dangereuses ou simplement une perte de temps pour le programme) comme:

A a;
a = a;

Votre opérateur d'affectation sera écrit:

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

this sur un compilateur C ++

Le compilateur C ++ recherchera silencieusement un symbole s'il ne le trouve pas immédiatement. Parfois, la plupart du temps, c'est bien:

• en utilisant la méthode de la classe mère si vous ne l'avez pas surchargée dans la classe enfant.
• la promotion d'une valeur d'un type dans un autre type

Mais parfois, vous ne voulez tout simplement pas que le compilateur devine. Vous voulez que le compilateur récupère le bon symbole et pas un autre.

Pour moi , ces moments sont ceux où, au sein d'une méthode, je souhaite accéder à une méthode membre ou à une variable membre. Je ne veux simplement pas qu'un symbole aléatoire soit ramassé simplement parce que j'ai écrit à la printfplace de print. this->printfn'aurait pas compilé.

Le fait est que, avec les bibliothèques héritées C (§), le code hérité écrit il y a des années (§§), ou tout ce qui pourrait arriver dans une langue où le copier / coller est une fonction obsolète mais toujours active, parfois, en disant au compilateur de ne pas jouer l'esprit est une excellente idée.

Ce sont les raisons que j'utilise this.

(§) c'est toujours une sorte de mystère pour moi, mais je me demande maintenant si le fait que vous incluez l'en-tête <windows.h> dans votre source, soit la raison pour laquelle tous les symboles de bibliothèques C hérités vont polluer votre espace de noms global

(§§) se rendre compte que "vous devez inclure un en-tête, mais que l'inclusion de cet en-tête cassera votre code car il utilise une macro stupide avec un nom générique" est l'un de ces moments de roulette russe de la vie d'un codeur

'ce.' aide à trouver des membres sur «cette» classe avec beaucoup de membres (généralement en raison d'une chaîne d'héritage profonde).

Frapper CTRL + Espace n'aide pas à cela, car il comprend également des types; où-comme «ceci». inclut les membres UNIQUEMENT.

Je le supprime généralement une fois que j'ai ce que je recherchais: mais c'est juste mon style qui perce.

En termes de style, si vous êtes un solitaire - vous décidez; si vous travaillez pour une entreprise, respectez la politique de l'entreprise (regardez ce qui se passe dans le contrôle des sources et voyez ce que font les autres). En termes d'utilisation pour qualifier les membres, ni l'un ni l'autre n'a tort ou raison. La seule mauvaise chose est l'incohérence - c'est la règle d'or du style. Laissez les autres à la cueillette. Passez votre temps à réfléchir à de vrais problèmes de codage - et évidemment à coder - à la place.

Je l'utilise chaque fois que je le peux. Je crois que cela rend le code plus lisible, et plus de code lisible équivaut à moins de bugs et plus de maintenabilité.

Lorsque vous êtes plusieurs développeurs travaillant sur la même base de code, vous avez besoin de quelques directives / règles de code. Là où je travaille, nous avons souhaité utiliser «ceci» sur les champs, les propriétés et les événements.

Pour moi, il est logique de le faire comme ça, cela rend le code plus facile à lire lorsque vous différenciez les variables de classe et les variables de méthode.

Cela dépend de la norme de codage sous laquelle je travaille. Si nous utilisons _ pour désigner une variable d'instance, alors "ceci" devient redondant. Si nous n'utilisons pas _, j'ai tendance à l'utiliser pour désigner une variable d'instance.

Je l'utilise pour invoquer Intellisense tout comme JohnMcG , mais je vais revenir en arrière et effacer "this->" quand j'aurai fini. Je suis la convention Microsoft de préfixer les variables membres avec "m_", donc le laisser comme documentation serait juste redondant.

1 - Idiome commun de définition de Java:

 public void setFoo(int foo) {
     this.foo = foo;
 }

2 - Lors de l'appel d'une fonction avec cet objet en paramètre

notifier.addListener(this);

Il y a une utilisation qui n'a pas déjà été mentionnée en C ++ et qui n'est pas de faire référence au propre objet ou de lever l'ambiguïté d'un membre d'une variable reçue.

Vous pouvez utiliser thispour convertir un nom non dépendant en un nom dépendant d'argument à l'intérieur de classes de modèles héritant d'autres modèles.

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

Les modèles sont compilés avec un mécanisme à deux passes. Lors de la première passe, seuls les noms non dépendants des arguments sont résolus et vérifiés, tandis que les noms dépendants ne sont vérifiés que pour leur cohérence, sans réellement remplacer les arguments du modèle.

À cette étape, sans réellement remplacer le type, le compilateur n'a presque aucune information de ce qui base<T>pourrait être (notez que la spécialisation du modèle de base peut le transformer en types complètement différents, même des types non définis), donc il suppose simplement qu'il s'agit d'un type . À ce stade, l'appel non dépendant fqui semble naturel au programmeur est un symbole que le compilateur doit trouver en tant que membre derivedou dans des espaces de noms fermés - ce qui ne se produit pas dans l'exemple - et il se plaindra.

La solution consiste à transformer le nom non dépendant fen un nom dépendant. Cela peut être fait de deux manières, en indiquant explicitement le type où il est implémenté ( base<T>::f- l'ajout de base<T>rend le symbole dépendant Tet le compilateur supposera simplement qu'il existera et reporte la vérification réelle de la deuxième passe, après substitution d'argument.

La deuxième façon, beaucoup de trieur si vous héritez de modèles qui ont plus d'un argument, ou des noms longs, consiste simplement à ajouter un this->avant le symbole. Comme la classe de modèle que vous implémentez dépend d'un argument (dont il hérite base<T>) this->dépend de l'argument, et nous obtenons le même résultat: this->fest vérifié au deuxième tour, après la substitution des paramètres du modèle.

Vous ne devez pas utiliser "ceci" à moins que vous ne deviez absolument le faire.

Il y a une pénalité associée à une verbosité inutile. Vous devez vous efforcer d'obtenir du code qui est exactement aussi long qu'il doit l'être, et non plus.