¿Cuándo utiliza la palabra clave "esto"? [cerrado]

Tenía curiosidad acerca de cómo otras personas usan esta palabra clave. Tiendo a usarlo en constructores, pero también puedo usarlo en toda la clase en otros métodos. Algunos ejemplos:

En un constructor:

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

En otra parte

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

Hay varios usos de esta palabra clave en C #.

1. Para calificar miembros ocultos por nombre similar
2. Hacer que un objeto se pase como parámetro a otros métodos
3. Hacer que un objeto regrese de un método
4. Para declarar indexadores
5. Para declarar métodos de extensión
6. Para pasar parámetros entre constructores
7. Para reasignar internamente el valor del tipo de valor (estructura) .
8. Para invocar un método de extensión en la instancia actual
9. Para lanzarse a otro tipo
10. Para encadenar constructores definidos en la misma clase

Puede evitar el primer uso al no tener variables miembro y locales con el mismo nombre en el alcance, por ejemplo, siguiendo convenciones de nomenclatura comunes y utilizando propiedades (caso Pascal) en lugar de campos (caso camello) para evitar chocar con variables locales (también camello). caso). En C # 3.0, los campos se pueden convertir en propiedades fácilmente mediante el uso de propiedades implementadas automáticamente .

No quiero decir que esto suene sarcástico, pero no importa.

Seriamente.

Mire las cosas que son importantes: su proyecto, su código, su trabajo, su vida personal. Ninguno de ellos tendrá éxito si dependerá de si utiliza o no la palabra clave "this" para calificar el acceso a los campos. La palabra clave this no lo ayudará a enviar a tiempo. No va a reducir errores, no tendrá ningún efecto apreciable en la calidad del código o la capacidad de mantenimiento. No le dará un aumento ni le permitirá pasar menos tiempo en la oficina.

Realmente es solo una cuestión de estilo. Si te gusta "esto", úsalo. Si no lo haces, entonces no lo hagas. Si lo necesita para obtener la semántica correcta, úselo. La verdad es que cada programador tiene su propio estilo de programación único. Ese estilo refleja las nociones de ese programador particular de cómo debería ser el "código más estéticamente agradable". Por definición, cualquier otro programador que lea su código tendrá un estilo de programación diferente. Eso significa que siempre habrá algo que hiciste que al otro chico no le gusta o que hubiera hecho de otra manera. En algún momento, un chico leerá tu código y se quejará de algo.

No me preocuparía por eso. Solo me aseguraría de que el código sea lo más estéticamente agradable posible según sus propios gustos. Si le preguntas a 10 programadores cómo formatear el código, obtendrás unas 15 opiniones diferentes. Una cosa mejor para enfocarse es cómo se factoriza el código. ¿Las cosas se abstraen bien? ¿Elegí nombres significativos para las cosas? ¿Hay mucha duplicación de código? ¿Hay formas de simplificar las cosas? Creo que hacer las cosas bien tendrá el mayor impacto positivo en su proyecto, su código, su trabajo y su vida. Casualmente, probablemente también hará que el otro tipo se queje menos. Si su código funciona, es fácil de leer y está bien factorizado, el otro tipo no examinará cómo inicializa los campos. Él solo va a usar su código, maravillarse de su grandeza,

Solo lo uso cuando es absolutamente necesario, es decir, cuando otra variable está sombreando a otra. Tal como aquí:

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;
    }

}

O como señala Ryan Fox, cuando necesita pasar esto como un parámetro. (Las variables locales tienen prioridad sobre las variables miembro)

Personalmente, trato de usar esto siempre cuando me refiero a las variables miembro. Ayuda a aclarar el código y hacerlo más legible. Incluso si no hay ambigüedad, alguien que lea mi código por primera vez no lo sabe, pero si ven que esto se usa de manera consistente, sabrán si están viendo una variable miembro o no.

Lo uso cada vez que me refiero a una variable de instancia, incluso si no lo necesito. Creo que hace que el código sea más claro.

No puedo creer que todas las personas que dicen que usarlo siempre sea una "mejor práctica" y tal.

Use "esto" cuando haya ambigüedad, como en el ejemplo de Corey o cuando necesite pasar el objeto como parámetro, como en el ejemplo de Ryan . No hay ninguna razón para usarlo de otra manera porque ser capaz de resolver una variable basada en la cadena de alcance debería ser lo suficientemente claro como para que las variables calificadas con él sean innecesarias.

EDITAR: La documentación de C # en "this" indica un uso más, además de los dos que mencioné, para la palabra clave "this" - para declarar indexadores

EDITAR: @Juan: Huh, no veo ninguna inconsistencia en mis declaraciones: hay 3 instancias en las que usaría la palabra clave "this" (como se documenta en la documentación de C #), y esos son momentos en los que realmente la necesita . Pegar "esto" frente a las variables en un constructor cuando no hay sombra es simplemente una pérdida de pulsaciones de teclas y una pérdida de mi tiempo al leerlo, no proporciona ningún beneficio.

Lo uso cuando StyleCop me dice que lo haga . StyleCop debe ser obedecido. Oh si.

Cada vez que necesite una referencia al objeto actual.

Un escenario particularmente útil es cuando su objeto está llamando a una función y quiere pasar a ella.

Ejemplo:

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

Tiendo a usarlo en todas partes también, solo para asegurarme de que esté claro que estamos tratando con miembros de instancias.

Lo uso en cualquier lugar donde pueda haber ambigüedad (obviamente). No solo la ambigüedad del compilador (se requeriría en ese caso), sino también la ambigüedad para alguien que mira el código.

Otro uso un tanto raro para esta palabra clave es cuando necesita invocar una implementación de interfaz explícita desde dentro de la clase de implementación. Aquí hay un ejemplo artificial:

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

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

Aquí es cuando lo uso:

• Acceso a métodos privados desde la clase (para diferenciar)
• Pasar el objeto actual a otro método (o como un objeto emisor, en caso de un evento)
• Al crear métodos de extensión: D

No uso esto para campos privados porque prefijo nombres de variables de campo privado con un guión bajo (_).

[C ++]

Estoy de acuerdo con la brigada "úsala cuando tengas que hacerlo". Decorar código innecesariamente con esto no es una gran idea porque el compilador no te avisará cuando olvides hacerlo. Esto introduce una posible confusión para las personas que esperan que esto siempre esté ahí, es decir, tendrán que pensarlo .

Entonces, ¿cuándo lo usarías? Acabo de echar un vistazo a algún código aleatorio y encontré estos ejemplos (no estoy juzgando si estas son buenas cosas para hacer o no):

• Pasar "usted mismo" a una función.
• Asignarse "usted mismo" a un puntero o algo así.
• Fundición, es decir, fundición ascendente / descendente (segura o no), desechando la constidad, etc.
• Desambiguación forzada del compilador.

Siempre debe usarlo, lo uso para diferenciar los campos y parámetros privados (porque nuestras convenciones de nomenclatura establecen que no usamos prefijos para los nombres de miembros y parámetros (y se basan en la información que se encuentra en Internet, por lo que considero que un mejores prácticas))

Lo uso cuando, en una función que acepta una referencia a un objeto del mismo tipo, quiero dejar perfectamente claro a qué objeto me refiero, dónde.

Por ejemplo

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() ;
  }
} ;

(vs)

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

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

De un vistazo, ¿a qué AABB se right()refiere? El thisagrega un poco de clarificador.

En la respuesta de Jakub Šturc, su # 5 sobre el paso de datos entre constructores probablemente podría usar una pequeña explicación. Esto está en sobrecargar a los constructores y es el caso en el que el uso de thises obligatorio. En el siguiente ejemplo, podemos llamar al constructor parametrizado desde el constructor sin parámetros con un parámetro predeterminado.

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

He encontrado que esta es una característica particularmente útil en ocasiones.

Tengo la costumbre de usarlo generosamente en Visual C ++, ya que al hacerlo activaría IntelliSense, presioné la tecla '>' y soy flojo. (y propenso a los errores tipográficos)

Pero he seguido usándolo, ya que me resulta útil ver que estoy llamando a una función miembro en lugar de una función global.

Tiendo a subrayar los campos con _ así que realmente nunca necesito usar esto. También R # tiende a refactorizarlos de todos modos ...

Prácticamente solo uso esto cuando hago referencia a una propiedad de tipo dentro del mismo tipo. Como otro usuario mencionó, también subrayo los campos locales para que sean notables sin necesidad de esto .

Lo uso solo cuando es necesario, excepto para operaciones simétricas que, debido al polimorfismo de un solo argumento, deben ponerse en métodos de un lado:

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

[C ++]

esto se usa en el operador de asignación donde la mayoría de las veces tiene que verificar y prevenir cosas extrañas (involuntarias, peligrosas o simplemente una pérdida de tiempo para el programa), como:

A a;
a = a;

Su operador de asignación se escribirá:

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 en un compilador de C ++

El compilador de C ++ buscará un símbolo en silencio si no lo encuentra de inmediato. A veces, la mayoría de las veces, es bueno:

• usando el método de la clase madre si no lo sobrecargó en la clase secundaria.
• promoviendo un valor de un tipo en otro tipo

Pero a veces, simplemente no quieres que el compilador adivine. Desea que el compilador recoja el símbolo correcto y no otro.

Para mí , esos momentos son cuando, dentro de un método, quiero acceder a un método miembro o variable miembro. Simplemente no quiero que se tome algún símbolo aleatorio solo porque escribí en printflugar de print. this->printfNo habría compilado.

El punto es que, con las bibliotecas heredadas de C (§), el código heredado escrito hace años (§§), o lo que pueda suceder en un lenguaje donde copiar / pegar es una característica obsoleta pero aún activa, a veces, le dice al compilador que no se reproduzca El ingenio es una gran idea.

Estas son las razones que uso this.

(§) sigue siendo una especie de misterio para mí, pero ahora me pregunto si el hecho de que incluya el encabezado <windows.h> en su fuente, es la razón por la cual todos los símbolos de bibliotecas C heredadas contaminarán su espacio de nombres global

(§§) darse cuenta de que "necesita incluir un encabezado, pero que incluir este encabezado romperá su código porque usa una macro tonta con un nombre genérico" es uno de esos momentos de la ruleta rusa en la vida de un programador

'esta.' ayuda a encontrar miembros en 'esta' clase con muchos miembros (generalmente debido a una cadena de herencia profunda).

Golpear CTRL + Espacio no ayuda con esto, porque también incluye tipos; donde-como 'esto'. incluye miembros SOLAMENTE.

Por lo general, lo elimino una vez que tengo lo que estaba buscando: pero este es solo mi estilo que se rompe.

En términos de estilo, si eres un llanero solitario, tú decides; si trabaja para una empresa, cumpla con la política de la empresa (mire las cosas en el control de código fuente y vea lo que otras personas están haciendo). En términos de usarlo para calificar miembros, ninguno es correcto o incorrecto. Lo único incorrecto es la inconsistencia, esa es la regla de oro del estilo. Deja a los pelos de punta otros. Dedique su tiempo a reflexionar sobre problemas de codificación reales, y obviamente codificación, en su lugar.

Lo uso cada vez que puedo. Creo que hace que el código sea más legible, y un código más legible equivale a menos errores y más facilidad de mantenimiento.

Cuando hay muchos desarrolladores que trabajan en la misma base de código, necesita algunas pautas / reglas de código. Donde trabajo, hemos decidido usar 'esto' en campos, propiedades y eventos.

Para mí tiene sentido hacerlo así, hace que el código sea más fácil de leer al diferenciar entre variables de clase y variables de método.

Depende del estándar de codificación con el que estoy trabajando. Si estamos usando _ para denotar una variable de instancia, entonces "esto" se vuelve redundante. Si no estamos usando _, entonces tiendo a usar esto para denotar la variable de instancia.

Lo uso para invocar a Intellisense como JohnMcG , pero volveré y borraré "esto->" cuando termine. Sigo la convención de Microsoft de prefijar las variables miembro con "m_", por lo que dejarlo como documentación sería redundante.

1 - Idioma común de Java setter:

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

2 - Al llamar a una función con este objeto como parámetro

notifier.addListener(this);

Hay un uso que aún no se ha mencionado en C ++, y que no se refiere al propio objeto o desambigua un miembro de una variable recibida.

Puede usar thispara convertir un nombre no dependiente en un nombre dependiente de argumento dentro de las clases de plantilla que heredan de otras plantillas.

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
   }
}

Las plantillas se compilan con un mecanismo de dos pasos. Durante el primer paso, solo se resuelven y verifican los nombres dependientes que no son argumentos, mientras que los nombres dependientes se verifican solo por coherencia, sin sustituir realmente los argumentos de plantilla.

En ese paso, sin sustituir realmente el tipo, el compilador casi no tiene información de lo que base<T>podría ser (tenga en cuenta que la especialización de la plantilla base puede convertirla en tipos completamente diferentes, incluso tipos indefinidos), por lo que simplemente asume que es un tipo . En esta etapa, la llamada no dependiente fque parece natural para el programador es un símbolo que el compilador debe encontrar como miembro dederived o en espacios de nombres adjuntos, lo que no ocurre en el ejemplo, y se quejará.

La solución es convertir el nombre no dependiente fen un nombre dependiente. Esto se puede hacer de dos maneras, indicando explícitamente el tipo donde se implementa ( base<T>::fagregando que base<T>hace que el símbolo dependa Ty el compilador asumirá que existirá y pospondrá la verificación real para el segundo pase, después de sustitución de argumentos

La segunda forma, mucho clasificador si hereda de plantillas que tienen más de un argumento, o nombres largos, es simplemente agregar un this->antes del símbolo. Como la clase de plantilla que está implementando depende de un argumento (hereda de base<T>) this->depende del argumento, y obtenemos el mismo resultado: this->fse verifica en la segunda ronda, después de la sustitución del parámetro de plantilla.

No debe usar "esto" a menos que sea absolutamente necesario.

Hay una penalización asociada con verbosidad innecesaria. Debes esforzarte por obtener un código que sea exactamente el tiempo necesario y no más.