¿Por qué StyleCop recomienda prefijar llamadas a métodos o propiedades con "this"?

Realmente no sigo esta guía a menos que esté en los escenarios que usted necesita:

• hay una actual ambigüedad - principalmente esto afecta a los constructores (this.name = name;) o cosas como Equals (return this.id == other.id;)
• desea pasar una referencia a la instancia actual
• desea llamar a un método de extensión en la instancia actual

Aparte de eso, considero este desorden. Así que apago la regla.

Creo que este artículo lo explica un poco

Http://blogs.msdn.microsoft.com/sourceanalysis/archive/2008/05/25/a-difference-of-style.aspx

...un joven y brillante desarrollador de Microsoft (ok, fui yo) decidió encargarse de escribir una pequeña herramienta que pudiera detectar variaciones del estilo C# utilizado dentro de su equipo. Nació StyleCop. Durante los próximos años, reunimos todas las pautas de estilo C # que pudimos encontrar de los diversos equipos dentro de Microsoft, y recogió todas las mejores prácticas que eran comunes a estos estilos. Estos formaron el primer conjunto de reglas de StyleCop. Una de las primeras reglas que surgieron de este esfuerzo fue el uso del prefijo this para llamar a los miembros de la clase, y la eliminación de cualquier prefijo de subrayado de los nombres de campo. El estilo C# había crecido oficialmente aparte de su antigua tribu C++.

this.This 
this.Does 
this.Not 
this.Add 
this.Clarity 
this.Nor 
this.Does 
this.This 
this.Add 
this.Maintainability 
this.To 
this.Code

El uso de " esto.", cuando se utiliza en exceso o un requisito de estilo forzado, no es nada más que un artificio utilizado bajo el pretexto de que hay

Tan pronto como comience a escribir, Intellisence mostrará el contenido disponible en el ámbito donde está escribiendo, "esto."no es necesario exponer a los miembros de la clase, y a menos que esté completamente despistado de lo que está codificando, debería poder encontrar fácilmente el artículo que necesita.

Incluso si no tienes ni idea, usa " esto."para insinuar lo que está disponible, pero no lo dejes en código. También hay una gran cantidad de complementos como Resharper que ayudan a traer claridad al alcance y exponer el contenido de los objetos de manera más eficiente. Es mejor aprender a usar las herramientas que se le proporcionan y luego desarrollar un mal hábito que es odiado por un gran número de tus compañeros de trabajo.

Cualquier desarrollador que no entienda inherentemente el alcance del contenido estático, local, de clase o global no debe confiar en "sugerencias" para indicar el alcance. "este."es peor que la notación húngara, ya que al menos la notación húngara proporcionó una idea sobre el tipo de referencia de la variable y sirve para algún beneficio. Prefiero ver " _ " o "m" usado para denotar los miembros del campo de clase que ver " esto." doquier.

Nunca he tenido un problema, ni he visto un problema con un compañero desarrollador que repetidamente lucha con el alcance del código o escribe código que siempre tiene errores debido a no usar " esto." explícita. Es un temor injustificado que " esto."previene futuros errores de código y es a menudo el argumento utilizado donde se valora la ignorancia.

Los programadores crecen con la experiencia, " esto."es como pedirle a alguien que ponga ruedas de entrenamiento en su bicicleta como adulto porque es lo que primero tuvo que usar para aprender a andar en bicicleta. Y un adulto podría caerse de una bicicleta 1 en 1,000 las veces que se suben, pero esa no es razón para obligarlos a usar ruedas de entrenamiento.

"esto."debería ser prohibido de la definición del lenguaje para C#, desafortunadamente solo hay una razón para usarlo, y es para resolver la ambigüedad, que también podría resolverse fácilmente a través de mejores prácticas de código.

Tenga en cuenta que al compilador no le importa si antepone las referencias con this o no (a menos que haya una colisión de nombres con una variable local y un campo o que desee llamar a un método de extensión en la instancia actual.)

Depende de tu estilo. Personalmente elimino this. del código, ya que creo que disminuye la relación señal / ruido.

Solo porque Microsoft usa este estilo internamente no significa que tengas que hacerlo. StyleCop parece ser una herramienta interna de MS que se ha hecho pública. Soy todo para adherirse a las convenciones de Microsoft en torno a las cosas públicas, tales como:

• los nombres de tipo están en PascalCase
• los nombres de los parámetros están en camelCase
• las interfaces deben ir precedidas por la letra I
• use nombres singulares para enumeraciones, excepto cuando sean [Banderas]

...pero lo que sucede en los ámbitos privados de su código es, bueno, privado. Haz lo que tu equipo esté de acuerdo.

La consistencia también es importante. Reduce la carga cognitiva cuando lectura de código, especialmente si el estilo de código es como se espera. Pero incluso cuando se trata de un estilo de codificación extranjero, si es consistente, entonces no tomará mucho tiempo acostumbrarse a él. Utiliza herramientas como ReSharper y StyleCop para garantizar la coherencia cuando creas que es importante.

El uso de.NET Reflector sugiere que Microsoft no es tan bueno para adherirse a los estándares de codificación de StyleCop en la BCL de todos modos.

Algunas razones básicas para usar this (y casualmente siempre antepongo los valores de clase con el nombre de la clase de la que también forman parte, incluso dentro de la propia clase).

1) Claridad. Sabes en este instante qué variables declaraste en la definición de la clase y cuáles declaraste como locales, parámetros y demás. En dos años, no lo sabrás e irás a un maravilloso viaje de redescubrimiento que es absolutamente inútil y no es necesario si indique específicamente el padre por adelantado. Alguien más que trabaja en su código no tiene idea desde el primer momento y, por lo tanto, se beneficia instantáneamente.

2) Intellisense. Si escribes esto.'usted obtiene todos los miembros y propiedades específicas de la instancia en la ayuda. Hace que encontrar las cosas sea mucho más fácil, especialmente si estás manteniendo el código de otra persona o el código que no has visto en un par de años. También le ayuda a evitar errores causados por conceptos erróneos de qué variables y métodos se declaran dónde y cómo. Puede ayudarte a descubrir errores que de otra manera no se mostrarían hasta que el compilador se atragantara con tu código.

3) Se puede lograr el mismo efecto mediante el uso de prefijos y otras técnicas, pero esto plantea la pregunta de por qué se inventaría un mecanismo para manejar un problema cuando hay un mecanismo para hacerlo construido en el lenguaje que es realmente soportado por el IDE? Si usted toca-tipo, incluso en parte, en última instancia, reducirá su tasa de error, también, al no obligarle a tomar los dedos fuera de la posición de inicio para llegar a la tecla de subrayado.

Veo un montón de programadores jóvenes que hacen un gran problema con el tiempo que ahorrarán al no escribir un carácter o dos. La mayor parte de su tiempo lo pasará depurando, no codificando. No te preocupes tanto por tu velocidad de escritura. Preocúpate más por la rapidez con la que puedes entender lo que está pasando en el código. Si te ahorras un total de cinco minutos de codificación y ganas gastando diez minutos extra de depuración, habrás ralentizado usted mismo abajo, no importa qué tan rápido usted mira como usted va.

Lo sigo, porque creo que es muy conveniente poder distinguir el acceso a los miembros estáticos y de instancia a primera vista.

Y, por supuesto, tengo que usarlo en mis constructores, porque normalmente doy a los parámetros del constructor los mismos nombres que el campo al que se asignan sus valores. Así que necesito "esto" para acceder a los campos.

Además, es posible duplicar nombres de variables en una función, por lo que usar 'this' puede hacerlo más claro.

class foo {
  private string aString;

  public void SetString(string aString){
    //this.aString refers to the class field
    //aString refers to the method parameter        
    this.aString = aString; 
  }
}

Lo sigo principalmente por razones intellisense. Es muy agradable escribir this. y obtener una lista consise de propiedades, métodos, etc.