¿Cuándo NO DE USAR esta palabra clave?

Question

Perdón por preguntarlo de nuevo, ya hay algunas preguntas sobre esta palabra clave. Pero todos ellos cuentan el propósito de 'esto'.

When do you use this keyword
C# when to use this keyword
Use of “this” keyword in formal parameters for static methods in C#
Proper usage of “this.” keyword in C#?

Mi pregunta es cuando no utilizar 'esto' palabra clave.
O
¿Está bien usar esta palabra clave siempre está en situación como el código

class RssReader 
{ 
    private XmlTextReader _rssReader; 
    private XmlDocument _rssDoc; 
    private XmlNodeList _xn; 

    protected XmlNodeList Item { get { return _xn; } } 
    public int Count { get { return _count; } } 

    public bool FetchFeed(String url) 
    { 
     this._rssReader = new XmlTextReader(url); 
     this._rssDoc = new XmlDocument(); 
     _rssDoc.Load(_rssReader); 
     _xn = _rssDoc.SelectNodes("/rss/channel/item"); 
     _count = _xn.Count; 
     return true; 
    } 
} 

aquí no he utilizado 'esto' con "_xn" y "_count" tampoco con "_rssDoc.Load (_lector de RSS);" ¿está bien? ¿Debo usar "esto" con todas las ocurrencias de variables de clase dentro de la clase?

Editar: ¿Es inútil utilizar 'esto' en una clase por sus propias variables?

Answer 1

this casi siempre es opcional y no es necesario que se determine. Si quiere ser explícito de que se está refiriendo a un miembro, entonces use this.Si tiene una convención de nomenclatura (como nombrar todos los campos de miembros, como _foo), entonces realmente no necesita referirse a ellos como this._foo.

Es una cuestión de gusto personal (sin penalización de rendimiento), pero me parece que tiene el explícito this es más difícil de mantener y agrega poco valor si tiene una convención de nomenclatura sólido. Algunas personas solo usarán this al llamar a un método miembro, p. this.Foo(_bar) en lugar de Foo(_bar), pero una vez más, personalmente no creo que agregue mucho.

Si está trabajando con el código existente, siga la convención allí; de lo contrario, elija el que lo haga más productivo y efectivo.

Answer 2

me gustaría tratar de ser consistentes, por lo que la gente no se confunda en el pensamiento de que los pocos que hace a la inversa (aparte de la forma en que normalmente se quiera) tienen un significado especial.

Si no usa la convención de nombres _whatever para los campos, entonces debe usar esto. Lo que sea consistentemente porque de lo contrario habrá problemas cuando los constructores tomen cualquier parámetro e intenten poner en cualquier campo.

Answer 3

Está bien. Especialmente porque su clase no tiene una clase base y los campos privados se nombran apropiadamente. ReSharper considera que this en su caso es redundante.

Answer 4

Mi regla de oro: Nunca use 'esto' cuando es redundante. En este caso, 'esto' es redundante, así que lo evitaría. Una herramienta como ReSharper es muy buena para decirte cuándo es el caso.

Answer 5

Es posible, pero no es necesario a menos que sea un método que toma argumentos con los mismos nombres que su clase de vars (para distinguirlos).

Answer 6

¿Debo usar "esto" con todas las ocurrencias de variables de clase dentro de la clase?

En su caso particular, NO.

considerar sin embargo, el siguiente ejemplo:

class RssReader 
{ 
    private String url; 

    public bool FetchFeed (String url) 
    { 
     new XmlTextReader (url); 

     // vs. 

     new XmlTextReader (this.url); 

     return true; 
    } 
} 

Aquí es necesario especificar this acceder a la variable de instancia que tiene el mismo nombre que el argumento de un método.

Answer 7

Bueno, en cuanto a mí, 'esto' se ve muy redundantes cuando se utiliza con nombres que comienzan con "_". Sin embargo, esto es absolutamente legal en tu ejemplo.

Answer 8

I siempre uso this. Utilizo la misma convención de nomenclatura para variables locales y campos privados, y hace que el código sea mucho más fácil de leer porque resulta obvio si el identificador utilizado es un campo o una variable local.

Además, previene la introducción de errores al agregar una nueva variable local que oculta un campo.

internal sealed class Foo 
{ 
    private Int32 bar = 42; 

    private void Bar() 
    { 
     // Uncommenting the following line will change the 
     // semantics of the method and probably introduce 
     // a bug. 
     //var bar = 123; 

     Console.WriteLine(bar); 

     // This statement will not be affected. 
     Console.WriteLine(this.bar); 
    } 
} 

Esto se puede evitar mediante el uso de diferentes convenciones de nombres de campos y variables locales, pero realmente no les gusta los nombres con el prefijo de subrayado. El primer carácter de una palabra es muy importante para su legibilidad y un guión bajo es una de las peores elecciones posibles.

Answer 9

Siempre uso this. para dejar en claro que me refiero a un miembro de la clase, no a una variable local.

Answer 10

no hay absolutamente ninguna razón para no utilizar esto. incluso la redundancia no es razón para no usarla, en absoluto. Usted obtiene el beneficio de la caja intellisense para completar su código de forma segura y le ahorra tiempo seleccionando la variable correcta con la tecla abajo y no manipulando su teclado todo el tiempo.

Answer 11

Así es como lo miro. Cuando llama a un miembro (ya sea método, propiedad o campo) de una clase como DoMyThing(); o return Property; dentro del alcance de la instancia, no es necesario que llame a un miembro de instancia. DoMyThing o Property pueden ser miembros estáticos también.

public class Abc 
{ 
    public static void Static() 
    { 
    } 

    public Xyz Instance; 

    public void Test() //instance scope 
    { 
     var xyz = Instance; //calls instance member 
     Static(); //calls static member 
    } 
} 

Para ambos (estática y la instancia) no he prefijado nada. En realidad, mis opciones son:

1. no uses el prefijo en absoluto que el anterior

   public void Test() 
   { 
       var xyz = Instance; 
       Static(); 
   } 
   

2. prefijo para los miembros de instancia solo

   public void Test() 
   { 
       var xyz = this.Instance; // prefixes 'this' 
       Static(); 
   } 
   

3. prefijo para los miembros estáticos solo

   public void Test() 
   { 
       var xyz = Instance; 
       Abc.Static(); //prefixes class 
   } 
   

4. prefijo en ambos casos

   public void Test() 
   { 
       var xyz = this.Instance; // prefixes 'this' 
       Abc.Static(); //prefixes class 
   } 
   

Esta respuesta es no quiere decir un estilo es mejor que otra. Esto es solo preferencia personal. Cada uno tiene su propio reclamo de corrección y legibilidad.

Mi opinión:

a. Por mi parte, no me gusta el estilo inconsistente de 2. y 3.

b. 1. tiene la ventaja de ser más legible para mí. La prefijación hace que sea más acerca de la definición que de la intención.

c. 4. se trata de corrección. Tiene la ventaja de ser extremadamente coherente, especialmente teniendo en cuenta que, de todos modos, se vería obligado a aplicar el prefijo para los miembros instance y static en algún momento. Esto es aún más importante a tener en cuenta cuando se trata de la palabra clave base, donde si no prefijas la palabra clave base para un miembro de la clase base, entonces agregar un miembro con el mismo nombre en la clase derivada actual hará que anule la llamada anterior, cambiando el dinámica completa.

Personalmente, me gustaría ir con 1. Y el uso de this o Abc con moderación cuando me veo obligado a. Es más legible para mí, un beneficio para mí que es lo suficientemente bueno como para compensar la poca inconsistencia que podría causar.