Y a-t-il des raisons de ne pas utiliser «ceci» («Soi», «Moi»,…)?

Question

J'ai lu cette réponse et ses commentaires, et je suis curieux: existe-t-il des raisons pour ne pas utiliser ce / Self / Moi ?

BTW: Je suis désolé si cela a déjà été demandé, il semble qu'il soit impossible de rechercher le mot this sur SO.

Answer 1

Avertissement: réponse purement subjective ci-dessous.

Je pense que la meilleure "raison" pour ne pas utiliser ceci / moi / moi est la brièveté. Si c'est déjà une variable / fonction membre, alors pourquoi ajouter le préfixe de manière redondante?

Personnellement, j’évite l’utilisation de this / self / me sauf s’il est nécessaire de lever l’ambiguïté d’une expression particulière pour le compilateur. Beaucoup de gens sont en désaccord avec cela, mais je n'ai jamais vu cela devenir un véritable point d'achoppement dans aucun groupe pour lequel j'ai travaillé.

Answer 2

Je pense que la plupart des scénarios courants ont été couverts dans les deux posts déjà cités; principalement brièveté et redondance vs clarté - un ajout mineur: en C #, il est nécessaire d’utiliser "this" pour accéder à une "méthode d'extension" pour le type actuel - c.-à-d.

this.Foo();

où Foo () est déclaré extérieurement comme suit:

public static void Foo(this SomeType obj) {...}

Answer 3

Cela clarifie dans certains cas, comme cet exemple dans c #:

public class SomeClass
{
    private string stringvar = "";

    public SomeClass(string stringvar)
    {
        this.stringvar = stringvar;
    }
}

Answer 4

Si vous utilisez StyleCop avec toutes les règles, cela vous oblige à insérer le this. . Depuis que j'ai commencé à l'utiliser, je trouve que mon code est plus lisible, mais c'est une préférence personnelle.

Answer 5

Je pense qu'il ne s'agit pas d'un problème, car cela ne fait qu'ajouter plus de lisibilité au code, ce qui est une bonne chose.

Pour certaines langues, comme PHP, il est même obligatoire de préfixer $ this- > si vous devez utiliser des champs ou des méthodes de classe.

Je n'aime pas le fait que certaines lignes sont inutilement plus longues qu'elles ne pourraient l'être, si PHP avait la possibilité de référencer les membres de la classe sans lui.

Answer 6

Je trouve personnellement que this.whats est moins lisible. Vous ne remarquerez peut-être pas la différence entre une méthode à 2 lignes, mais attendez d’avoir this.variable et this.othervariable partout dans une classe.

De plus, je pense que l’utilisation de this. a été trouvée en remplacement d’une partie de la très réputée notation hongroise. Certaines personnes ont découvert qu'il était toujours plus clair pour le lecteur de voir qu'une variable était un membre de la classe, et this. a fait l'affaire. Mais pourquoi nous leurrer et ne pas utiliser le vieux code "m_" ou simplement "_" pour cela, si nous avons besoin de plus de clarté? C'est 5 personnages contre 2 (ou même 1). Moins de frappe, même résultat.

Cela dit, le choix du style reste une question de préférence personnelle. Il est difficile de convaincre une personne habituée à lire le code d’une manière utile pour le changer.

Answer 7

Eh bien, eclipse colorie les champs, les arguments et les variables locales de différentes couleurs. Par conséquent, pour travailler au moins dans un environnement eclipse, il n’est pas nécessaire de distinguer syntaxiquement les champs pour les marquer spécialement comme "champs". pour vous et les générations à venir.

Answer 8

Cela a déjà été demandé dans la "variable in java". contexte:

Préfixez-vous votre variable d'instance avec "this" en java?

La principale raison récurrente semble être:

  

"Cela augmente le bruit visuel que vous devez parcourir pour trouver la signification du code."

Lisibilité, autrement dit ... que je n’achète pas, je trouve ceci. très utile.

Answer 9

Cela me semble absurde. L'utilisation de 'ceci' peut rendre le code plus agréable, et je ne vois aucun problème avec cela. Des politiques comme celle-là sont stupides (du moins lorsque vous ne dites même pas aux gens pourquoi elles sont en place).

Answer 10

'ça.' dans le code me suggère toujours que le codeur a utilisé intellisense (ou d’autres équivalents IDE) pour faire son travail.

Je suis certainement coupable de cela, mais je les enlève par la suite pour des raisons purement personnelles.

Les seules autres raisons pour lesquelles je les utilise sont pour qualifier une variable ambiguë (mauvaise pratique) ou pour construire une méthode d'extension

Qualifier une variable

string name; //should use something like _name or m_name

public void SetName(string name)
{
     this.name = name;
}

Answer 11

comme pour moi j'utilise this pour appeler les méthodes d'un objet instancié alors que self est pour une méthode statique

Answer 12

Dans VB.NET, l’une des pratiques courantes que j’utilise est le code suivant:

Class Test
    Private IntVar AS Integer
    Public Function New(intVar As Integer)
       Me.Intvar = intvar
    End Function    
End Class

Pas tout le temps mais surtout moi / cela / moi est très utile. Clarifie la portée de votre conversation.

Answer 13

Dans une méthode de définition typique (extraite de la réponse de lagerdalek):

string name;

public void SetName(string name)
{
     this.name = name;
}

Si vous ne l'utilisez pas, le compilateur ne saura pas que vous faites référence à la variable membre.
L'utilisation de this. consiste à indiquer au compilateur que vous devez accéder à une variable membre, qui se situe en dehors de la portée immédiate de la méthode. La création d'une variable au sein d'une méthode portant le même nom qu'une variable membre est parfaitement légale, tout comme le fait de remplacer une méthode dans une classe qui a étendu une autre classe est parfaitement légal.
Cependant, si vous devez toujours utiliser la méthode de la classe super, utilisez super. . n'est pas pire que d'utiliser super. et permet au programmeur plus de flexibilité dans leur code.

En ce qui me concerne, la lisibilité n’entre même pas en ligne de compte, il s’agit de l’accessibilité de vos variables.

Answer 14

Au final, c’est toujours une question de choix personnel. Personnellement, j'utilise cette convention de codage:

public class Foo
{
  public string Bar
  {
    get
    {
      return this.bar;
    }
    /*set
    {
      this.bar = value;
    }*/
  }
  private readonly string bar;

  public Foo(string bar)
  {
    this.bar = bar;
  }
}

Donc pour moi "ça" est en fait nécessaire pour que le constructeur reste lisible.

Modifier: le même exemple exact a été envoyé par " sinje " alors que j'écrivais le code ci-dessus.

Answer 15

Non seulement j’utilise fréquemment "this". J'utilise parfois "ça".

class Foo
{
    private string bar;

    public int Compare(Foo that)
    {
        if(this.bar == that.bar)
        {
            ...

Et ainsi de suite. " Cela " dans mon code signifie généralement une autre instance de la même classe.