¿Cuáles son las mejores prácticas actuales consideradas con respecto a la palabra clave "this" delante del campo y los métodos en c #?

A menos que sea necesario diferenciar entre una variable y un campo con el mismo nombre, nunca pongo this.delante de un campo o acceso de ningún miembro en C #. Veo esto como algo diferente al m_prefijo que solía ser común en C ++, y creo que si realmente necesita especificar que es un miembro, su clase es demasiado grande.

Sin embargo, hay varias personas en mi oficina que están totalmente en desacuerdo.

¿Con qué se consideran las mejores prácticas actuales this.?

EDITAR: Para aclarar, nunca uso m_y solo uso this.cuando es absolutamente necesario.

De acuerdo con las pautas de diseño del Marco , cuando se hace referencia a campos públicos o protegidos:

NO use un prefijo para los nombres de campo.

Por ejemplo, m_es un prefijo.

Entonces, la exposición pública de un campo se presta al uso de la thispalabra clave como se explica en MSDN

Para calificar miembros ocultos por nombres similares, por ejemplo: Copiar

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

Al referirse a campos privados, puede usar el m_si lo desea. Pero, para los campos públicos, recomiendo seguir las mejores prácticas.

Personalmente, no me gustan los guiones bajos en mis nombres de variables. También trato de ser consistente. Por lo tanto, this.name = name;es una buena regla general trabajar en escenarios públicos / privados.

En nuestro equipo, hemos adoptado el estándar de usar el calificador this.u Me.objeto en clases más grandes para ayudar a los desarrolladores junior a distinguir más fácilmente el alcance exacto / inmediato de una variable con solo mirarla.

En cuanto al código, es una afectación completamente innecesaria, pero no bloquea nada ya que genera el mismo código MISL exacto al final de todos modos. Lo hemos adoptado solo porque aborda un problema inmediato que descubrimos con algunos de los juniors. Más allá de eso, no veo que sea útil incluirlo.

StyleCop impondrá el uso de this.So, si considera que es la mejor práctica (que yo hago), entonces el uso de this.es la mejor práctica.

El estilo que adopte depende de usted y de sus propios estándares de codificación, "mejor" es lo que usted defina. Solo sé consistente. Usarlo de manera inconsistente solo conduce a la confusión.

Mi razonamiento es que el uso this.señala el hecho de que hace referencia a las propiedades de la instancia, por lo que, por ejemplo, ayuda a resaltar el hecho de que las está mutando (si es que las tiene this.x = ...), que es algo que quizás desee saber. También destaca el hecho de que cada vez que veas this.tu método nunca puede ser estático. Usar alguna convención como m_también también lo hará, pero es un esfuerzo manual, si convierte un m_método estático o refactoriza algún método para pasar el valor desde fuera de la clase, entonces debe recordar cambiar el nombre, si estaba usando thisentonces el compilador lo obligará a hacer el cambio.

En pocas palabras, usarlo thises más fácil porque si te equivocas, tu código no se compilará, si lo usas m_es un esfuerzo manual y no estás aprovechando las herramientas.

Una de las cosas buenas de usar m_es que tan pronto como escribe el pequeño mintellisense le da una lista de todas sus variables privadas, personalmente creo que es un plus a su favor; También iría s_por estadísticas privadas y c_constantes privadas por razones similares. Es una notación húngara, pero en el sentido en que se entiende porque agrega un significado útil al nombre de la variable para que cualquier otro programador pueda decir cosas al respecto de su nombre que pueden no ser totalmente obvias.

Ciertamente no estoy de acuerdo con no tener ninguna forma de distinguir entre las variables miembro y no miembro porque son diferentes y cuando leo el código donde la gente no hace algo para distinguirlo es realmente más difícil de leer. Usar this.solo se siente como más placa de caldera de la necesaria. Pero en realidad es un gusto personal, si codifica de una manera por un tiempo, termina pensando que está bien y todo lo demás está mal. Lo único que realmente importa si el esquema es sensato es que todos en el equipo sean consistentes.

thises explícito Es una señal óptica que no te puedes perder.

Casi siempre prefiero el código explícito sobre el código implícito. Por eso lo uso con thisfrecuencia. Lo considero una mejor práctica.

Yo siempre uso "esto". El razonamiento se basa en dos hechos simples:

• Leer el código es más difícil que escribirlo.
• Lees el código con más frecuencia que lo escribes.

El uso de "esto" hace que sea bastante explícito para cualquiera que lea (es decir, no solo el autor, sino que puede incluir al autor dentro de 6 meses después de que se hayan olvidado por completo los detalles de la implementación) que sí, este es un miembro de la clase que " estoy hablando aquí. "m_" y similares son solo una convención, y como cualquier otra convención puede ser mal utilizada (o no utilizada en absoluto): no hay nada que imponga "m _" / etc en tiempo de compilación o tiempo de ejecución. "esto" es más fuerte: puede poner "m_" en una variable local y el compilador no se quejará; no puedes hacer eso con "esto".

En todo caso, considero lamentable que el uso de "esto" no sea obligatorio en las especificaciones de idioma.

Como un buen bono, al depurar puede pasar el mouse (o agregar un reloj para) "esto" y obtener la inspección de todos los demás miembros de la clase, información valiosa.

La thispalabra clave se usa particularmente para distinguir 2 variables que existen, especialmente cuando tiene un constructor o método con una variable con el mismo nombre pero puede tener el mismo tipo.

Ejemplo:

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

Esto (p this.reason = reason. Ej. ) Básicamente asigna el valor de los parámetros a las variables de la clase. thisbásicamente toma la clase reasondel bloque de parámetros.

También me he estado preguntando sobre eso por algún tiempo. Después de hacer una codificación extensa en javascript, me sorprendí usando this.más a menudo en mi código c # (antes de eso lo usé casi exclusivamente en constructores o métodos similares para evitar la ambigüedad). Hace que el código sea un poco más claro para un pequeño esfuerzo adicional, además, no terminas mutilando los nombres de los miembros de tu clase con prefijos y aún puedes volver a usar los miembros 'de manera breve' cuando el contexto es claro o en declaraciones particularmente complejas. Solo agrego this., cuando tengo un método más largo, una lista de argumentos más larga o muchas variables locales declaradas y creo que el código podría beneficiarse de una claridad adicional, incluso si es forzado.

Pero personalmente odio absolutamente el m_estilo de prefijo, no tanto por el húngaro, sino porque el guión bajo es difícil de escribir;) Así que no lo considero una alternativa. Admito que tiene sus puntos fuertes cuando se trata de intellisense, sin embargo, nuevamente podría argumentar que si no puede recordar las primeras letras de una variable miembro, su clase es demasiado grande.

Preveo un solo prefijo de subrayado para los miembros de la clase _someVar;

¿Por qué? Usted sabe a primera vista que es un miembro, no una variable de pila. Solo conveniencia durante un vistazo rápido. Y se necesita menos desorden en comparación con la palabra clave "this".

Usar cosas como el this.prefijo / palabra clave que no son necesarias ni cambian el resultado es siempre subjetivo. Sin embargo, creo que podemos estar de acuerdo en que la mayoría de nosotros queremos diferenciar los campos de las variables locales. Algunos usan un prefijo de subrayado (que me parece feo y una especie de notación húngara), otros usan la this.palabra clave. Soy uno de estos últimos. Se trata solo de legibilidad y comprensibilidad. No me importa escribir un poco más si es más claro o más legible. Quiero diferenciar campos y variables en un abrir y cerrar de ojos.

Siempre defino campos con nombres similares myFieldy nombres de parámetros y nombres de variables locales también similares a myField. Sin guiones bajos, sin prefijos. Lo uso en thistodas partes me refiero a un campo. De esta manera puedo distinguir campos de variables locales y argumentos sin ningún tipo de prefijo. Por supuesto, en un caso como este thisse requiere la palabra clave:

public Person(string firstName)
{
    this.firstName = firstName;
}

Por lo tanto, mis propiedades se ven así (sí, siempre pongo el campo con la propiedad, y no en algún lugar no relacionado en la parte superior de mi archivo):

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

Se lee bien: devuelve este primer nombre .

EDITAR: Mi respuesta claramente no es una respuesta. Así que aquí hay una edición. Las pautas de codificación de Microsoft establecen:

2.6 Nombramiento

No use un prefijo para las variables miembro ( , m , s_, etc.). Si desea distinguir> entre variables locales y miembros, debe usar "this" en C # y "Me" en VB.NET.

Se puede encontrar en: http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Por lo tanto, parece que al menos desde MS no hay una directriz clara, aunque otra respuesta afirma que StyleCop la convierte en una directriz. No hay autoridad en estas cosas, por lo que le sugiero que tome una decisión, o en este caso ceda ante su equipo. No es un gran problema.

Mi respuesta original Estoy personalmente de acuerdo con usted, pero tal vez una prueba de comprensión de lectura que enfrente los dos métodos sería valiosa. De lo contrario, estas cosas de estilo son simplemente confusas.

Mi salvamento a seguir: mi opinión es que las personas están complicando innecesariamente su estilo de código, y si necesitan indicar que algo es una variable de nivel de clase, puede haber otros problemas estructurales serios en el código, como el antiguo método de receta de colocando variables privadas en la parte superior de la clase que lo obligan a desplazarse constantemente hacia arriba y hacia abajo.

esto me parece una de esas convenciones de "qué es esto" versus las convenciones de nomenclatura correcta de "lo que hace". Se debe favorecer la brevedad antes que ser explícito. Esta es una lección que se repite a menudo por lenguajes dinámicos. ¡No necesitamos toda la pelusa!

esta. A menudo puede conducir a ruidos no deseados.

Aquí está mi solución:

• nombre_parámetros_
• variables_locales
• CUALQUIER_CONSTANTE
• _privados_miembros
• Propiedades no privadas
• _NonPrivateProperty // Backer
• propiedad privada
• _privateProperty // patrocinador