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

De acuerdo con las Directrices de diseño del marco , cuando haga referencia a campos públicos o protegidos:

  

NO usa un prefijo para los nombres de los campos.

Por ejemplo, m_ es un prefijo.

Por lo tanto, la exposición pública de un campo se presta al uso de la palabra clave this como se explica en MSDN

  

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

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

Al referirse a campos privados, puede usar 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 para trabajar en escenarios públicos / privados.

En nuestro equipo, hemos adoptado el estándar de usar el calificador de objeto this. o Me. 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. p>

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

StyleCop aplicará el uso de this. Por lo tanto, si considera que es la mejor práctica (lo que hago), entonces el uso de this. es la mejor práctica.

El estilo que adoptes depende de usted y de sus propios estándares de codificación, "mejor" es lo que usted define que es. Solo sé consistente. Su uso inconsistente solo conduce a la confusión.

Mi razonamiento es que usar this. indica el hecho de que estás haciendo referencia a las propiedades de la instancia, por lo que, por ejemplo, es útil resaltar el hecho de que las estás mutando (si tienes this.x = ... ), que es algo es posible que desee saber acerca de También destaca el hecho de que cada vez que vea this. , su método nunca puede ser estático. Usar alguna convención como m_ también lo hará, pero es un esfuerzo manual, si convierte un m_ en una estática, o refactoriza algún método para pasar el valor desde fuera de la clase, entonces debe recordar cambiar el nombre, si estabas usando this entonces el compilador te obligará a hacer el cambio.

Poner simplemente el uso de this es más fácil porque si lo hace mal, su código no se compilará, si usa m_ es un esfuerzo manual y no está aprovechando las herramientas.

Una de las cosas agradables sobre el uso de m_ es que, tan pronto como escribes, el pequeño m intellisense te da una lista de todas tus variables privadas, personalmente creo que es una ventaja a su favor. También iría s_ para estadísticas privadas y c_ para constantes privadas por razones similares. Es una notación húngara, pero en el sentido en que se entendió porque agrega un significado útil al nombre de variable para que cualquier otro programador pueda decir cosas sobre él a partir de su nombre que no sea totalmente obvio.

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 las personas no hacen algo para destruirlo, es realmente más difícil de leer. Usar this. solo se siente como más placa de caldera de lo necesario. Pero en realidad es un gusto personal, si codificas una forma por un tiempo, terminas pensando que está bien y todo lo demás está mal. Lo único que realmente importa si el esquema es sensato es que todos los miembros del equipo sean coherentes.

this es explícito. Es un signo óptico que no te puedes perder.

Casi siempre prefiero el código explícito sobre el código implícito. Es por eso que uso this con frecuencia. Considero que es una buena práctica.

La palabra clave this se usa particularmente para distinguir 2 variables que existen, especialmente cuando tienes 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 (por ejemplo, this.reason = reason ) básicamente asigna el valor de los parámetros a las variables en la clase. this básicamente toma la clase reason del bloque de parámetros.

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

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

El uso de "esto" lo hace 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í, esta es una clase miembro del que estamos hablando aquí. "m_" y similares es solo una convención, y como cualquier otra convención, puede ser mal utilizada (o no usarse en absoluto), no hay nada que imponga "m _" / etc ni en tiempo de compilación ni en 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".

Si algo me parece lamentable, el uso de "esto" no se hizo obligatorio en las especificaciones de idioma.

Como un bono agradable, al depurar puede desplazarse (o agregar un reloj) al "esto" y obtener una inspección de todos los demás miembros de la clase también - información valiosa.

También me he estado preguntando acerca de eso por algún tiempo. Después de hacer una codificación extensa en javascript, me encontré 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 termina de mutilar los nombres de los miembros de su clase con prefijos y aún puede volver a usar los miembros "de manera breve" cuando el contexto es claro o en declaraciones particularmente complejas. Simplemente 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 cierta claridad adicional, incluso si es forzado.

Pero, personalmente, odio el estilo de prefijo m_ , no tanto por el húngaro, sino porque subrayar es un problema para escribir;) Por lo tanto, no lo considero una alternativa. Admito que tiene sus puntos fuertes cuando se trata de inteligencia, sin embargo, podría argumentar nuevamente que si no puede recordar las primeras letras de una variable miembro, su clase es demasiado grande.

Prefiero un único prefijo de subrayado para los miembros de la clase. _someVar;

¿Por qué? Al principio, sabes que es un miembro, no una variable de pila. Solo conveniencia durante una mirada rápida. Y se necesita menos desorden en comparación con la palabra clave "this".

Usar elementos como el prefijo / palabra clave this. que no son necesarios ni cambiar el resultado siempre es 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 palabra clave this. . Soy uno de los últimos. Todo se trata 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 a myField y nombres de parámetros y variables locales también similares a myField . Sin guiones bajos, ni prefijos. Yo uso this en todas partes me refiero a un campo. De esta manera puedo distinguir los campos de las variables locales y los argumentos sin ningún tipo de prefijo. Por supuesto, en un caso como este, se requiere la palabra clave this :

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

Por lo tanto, mis propiedades tienen este aspecto (sí, siempre coloco el campo con la propiedad, y no en un lugar no relacionado en la parte superior de mi archivo):

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

Se lee bien: devolver este nombre .

esto. a menudo puede conducir a ruidos no deseados.

Aquí está mi solución:

• parameters_names_
• local_variables
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty // Backer
• privateProperty
• _privateProperty // patrocinador

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

  

2.6 Naming

     

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

Se puede encontrar en: enlace

Por lo tanto, parece que al menos de MS no hay una guía clara, aunque otra respuesta indica que StyleCop lo convierte en una guía. No hay autoridad sobre estas cosas, por lo que te sugiero que te decidas por ti mismo o, en este caso, cede a tu equipo. No es tan importante.

Mi respuesta original Personalmente estoy de acuerdo con usted, pero tal vez una prueba de comprensión de lectura que haga coincidir los dos métodos sea valiosa. De lo contrario, estas cosas de estilo son simplemente confusas.

Mi salvo a seguir: Mi opinión es que las personas están complicando innecesariamente el estilo de su código, y si necesitan indicar que algo es una variable de nivel de clase, podría haber otros problemas estructurales graves en el código, como el antiguo método de receta de poner variables privadas en el lugar. parte superior de la clase que te obliga a desplazarte constantemente hacia arriba y hacia abajo.

esto me parece una de esas convenciones de "qué es esto" frente a las convenciones de denominación correctas de "lo que hace". La brevedad debe ser favorecida por encima de ser explícita. Esta es una lección que se repite a menudo por lenguajes dinámicos. ¡No necesitamos toda la pelusa!