c# - tutorial - stylecop visual studio 2017
¿Por qué StyleCop recomienda el método de prefijo o las llamadas a propiedades con "this"? (9)
He estado tratando de seguir las pautas de StyleCop en un proyecto, para ver si el código resultante era mejor al final. La mayoría de las reglas son razonables o una cuestión de opinión sobre el estándar de codificación, pero hay una regla que me desconcierta, porque no he visto a nadie más recomendarla, y porque no veo un claro beneficio para ella:
SA1101: la llamada a {method o property name} debe comenzar con ''this.'' prefijo para indicar que el elemento es miembro de la clase.
En el lado negativo, el código es claramente más detallado de esa manera, ¿cuáles son los beneficios de seguir esa regla? ¿Alguien aquí sigue esa regla?
Además, es posible duplicar los nombres de las variables en una función, por lo que usar ''esto'' 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;
}
}
Algunas razones básicas para usar this (y casualmente siempre prefijo los valores de clase con el nombre de la clase de la que también forman parte, incluso dentro de la misma clase).
1) Claridad. En este instante, sabes qué variables declaraste en la definición de clase y cuáles declaraste como locals, parameters y whatnot. En dos años, no lo sabrá y realizará un maravilloso viaje de redescubrimiento que es completamente inútil y no es necesario si usted declara específicamente al padre por adelantado. Alguien más trabajando en su código no tiene idea desde el principio y, por lo tanto, se beneficia instantáneamente.
2) Intellisense. Si escribe ''esto''. obtienes todos los miembros y propiedades específicos de la instancia en la ayuda. Hace que encontrar las cosas sea mucho más fácil, especialmente si mantienes el código o el código de otra persona que no has examinado 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 ayudarlo a descubrir errores que de lo contrario no aparecerían hasta que el compilador se ahogara en su código.
3) Concedido, se puede lograr el mismo efecto usando 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 integrado en el lenguaje que realmente es compatible con el IDE? Si toca tipo, incluso en parte, en última instancia, reducirá su tasa de error, también, al no forzarlo a sacar sus dedos de la posición inicial para llegar a la tecla de subrayado.
Veo muchos programadores jóvenes que hacen una gran cosa del tiempo que ahorrarán al no escribir un personaje o dos. Dedicará la mayor parte de su tiempo a la depuración, no a la codificación. No se preocupe tanto por su velocidad de tipeo. Preocúpese más por cuán rápido puede comprender lo que está sucediendo en el código. Si ahorra un total de cinco minutos de codificación y gana gastando diez minutos adicionales en la depuración, se ha ralentizado, no importa qué tan rápido parezca que va.
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 brillante joven desarrollador en Microsoft (bueno, fui yo) decidió encargarse de escribir una pequeña herramienta que podría detectar variaciones del estilo C # utilizado en su equipo. StyleCop nació. En los siguientes años, reunimos todas las pautas de estilo de C # que pudimos encontrar de los diversos equipos de Microsoft, y seleccionamos 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 de este prefijo para llamar a los miembros de la clase y la eliminación de los prefijos de subrayado de los nombres de campo. El estilo C # se había separado oficialmente de su antigua tribu C ++.
Lo sigo principalmente por razones intelectuales . Es muy lindo escribir this. y obtener una lista de propiedades, métodos, etc.
Lo sigo, porque creo que es muy conveniente poder diferenciar el acceso a miembros estáticos y de instancias a primera vista.
Y, por supuesto, tengo que usarlo en mis constructores, porque normalmente le doy a los parámetros del constructor los mismos nombres que el campo al que se asignan sus valores. Entonces necesito "esto" para acceder a los campos.
Puede hacer que el código sea más claro a simple vista. Cuando utilizas this , es más fácil:
- Diga los miembros estáticos y de instancia aparte. (Y distinguir los métodos de instancia de los delegados).
- Distinga los miembros de la instancia de las variables locales y los parámetros (sin utilizar una convención de nomenclatura).
Realmente no sigo esta guía a menos que esté en los escenarios que necesita:
- hay una ambigüedad real , principalmente esto afecta a los constructores (
this.name = name;) o cosas comoEquals(return this.id == other.id;) - quieres 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. Entonces apago la regla.
Tenga en cuenta que al compilador no le importa si prefija las referencias con this o no (a menos que haya una colisión de nombre con una variable local y un campo o si desea 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.
El hecho de que Microsoft use este estilo internamente no significa que deba hacerlo. StyleCop parece ser una herramienta interna de MS que se ha hecho pública. Estoy a favor de adherirme a las convenciones de Microsoft sobre cosas públicas, tales como:
- los nombres tipo están en PascalCase
- los nombres de los parámetros están en camelCase
- las interfaces deben ir precedidas de la letra I
- usa nombres singulares para enumeraciones, excepto cuando son [Banderas]
... pero lo que sucede en los dominios privados de tu código es, bueno, privado. Haz lo que sea que tu equipo acuerde.
La consistencia es también importante. Reduce la carga cognitiva al leer el código, especialmente si el estilo del código es el que usted espera. Pero incluso cuando se trata de un estilo de codificación extraño, si es consistente, no tardará en acostumbrarse a él. Use herramientas como ReSharper y StyleCop para garantizar la coherencia donde cree que es importante.
El uso de .NET Reflector sugiere que Microsoft no es tan bueno en adherirse a los estándares de codificación de StyleCop en el BCL de todos modos.
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 usa excesivamente o un requisito de estilo forzado, no es más que un artilugio bajo el disfraz de que hay <1% de desarrolladores que realmente no entienden el código o lo que están haciendo, y lo hace doloroso para el 99% que quiere escribir código fácil de leer y fácil de mantener.
Tan pronto como comience a escribir, Intellisence listará el contenido disponible en el ámbito de donde está escribiendo "esto". no es necesario para exponer a los miembros de la clase y, a menos que no tenga ni idea de lo que está codificando, debería poder encontrar fácilmente el elemento que necesita.
Incluso si no tiene ni idea, use "esto". para insinuar lo que está disponible, pero no lo deje en el código. También hay una gran cantidad de complementos como Resharper que ayudan a dar 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 una gran cantidad de compañeros de trabajo.
Cualquier desarrollador que no comprenda inherentemente el alcance del contenido estático, local, de clase o global no debe confiar en "pistas" para indicar el alcance. "esta." es peor que la notación húngara, como mínimo, la notación húngara proporciona una idea sobre el tipo al que hace referencia la variable y sirve para algunos beneficios. Preferiría ver "_" o "m" para denotar a los miembros del campo de clase y luego ver "esto". en todos lados.
Nunca he tenido un problema, ni he visto un problema con un desarrollador compañero que pelea repetidamente con el alcance del código o escribe un código que siempre tiene fallas debido a que no se usa "esto". explícitamente. Es un miedo injustificado que "esto". previene futuros errores de código y es a menudo el argumento usado donde se valora la ignorancia.
Los codificadores crecen con 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 los adultos pueden caerse de una bicicleta 1 en 1,000 veces que la suben, pero esa no es una razón para obligarlos a usar ruedas de entrenamiento.
"esta." debería estar prohibido en la definición de 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.