C # - ¿Por qué se desalientan los prefijos en los campos?

En los viejos tiempos, hicimos notación húngara. Eso ahora se considera pasado y, en su mayor parte, ya no lo uso, pero todavía encuentro uso para el m_prefijo para indicar campos de miembros.

Para mí, si estoy leyendo el código de otra persona y veo esto:

count = 3;

Supongo que countes una variable local para esa función y estoy haciendo algo que se usará en otra parte de la función; si veo esto:

m_count = 3;

Inmediatamente me doy cuenta de que estoy actualizando el estado del objeto.

Las pautas de estilo de Microsoft dicen que esa es la forma incorrecta de hacer las cosas. Se supone que debo nombrar mis campos no públicos exactamente como las variables temporales definidas dentro de la función. No m_, ni siquiera un simple guión bajo.

Sí, podemos definir nuestro propio estilo de codificación, pero luego tengo que luchar con varias herramientas de análisis de código estático, para convencerlos de que nuestra forma de hacer las cosas está bien.

Estoy feliz de cambiar al estilo de Microsoft, pero me gustaría saber por qué las cosas son como son.

¿Por qué ahora se considera malo saber si una variable es una función local o un miembro?

PD Esto es muy similar a ¿Cuáles son las mejores prácticas actuales consideradas con respecto a la palabra clave "this" en frente del campo y los métodos en c #? , pero estoy preguntando por m_nothis.

PPS También vea ¿Por qué Microsoft hizo que los parámetros, las variables locales y los campos privados tengan la misma convención de nomenclatura de nombres?

Cuando estaban trabajando en la API para Windows, Microsoft recomendó el uso de la notación húngara, usando 'm_', así como 'i', 'sz', etc. En ese momento, esto fue útil porque el IDE no era robusto suficiente para mostrarle esta información.

C #, por otro lado, tiene un IDE muy robusto desde el principio.

Entonces hicieron la recomendación en las Pautas de nomenclatura de Microsoft para C # para campos públicos estáticos o protegidos:

✓ DO use PascalCasing in field names.
✓ DO name fields using a noun, noun phrase, or adjective.
X DO NOT use a prefix for field names.

Ahora que puede desplazarse sobre él con el mouse o presionar CTRL + K + W y obtener toda la información sobre el miembro, Microsoft llegó a la determinación de que los prefijos son incorrectos; Son una solución manual a un problema ya resuelto.

Los campos privados están específicamente excluidos de las pautas, pero Microsoft parece haber llegado a la conclusión de que este es el caso incluso para los campos privados que avanzan internamente, lo que puede ver si apunta Resharper a .NET 4.5 o .NET Core.

Usa tus herramientas, no lo hagas manualmente.

C # no tiene ninguna variable global, por lo que solo deja variables locales y campos de clase.

Y si tiene tantas variables locales que pierde la noción de si un identificador es uno, seguramente ha violado una de las pautas para gestionar la complejidad de manera más grave.

Intente extraer un objeto de parámetro, intente dividir su función en múltiples más simples, seguramente debería refactorizar su código a menos que le guste ahogarse en minucias y complejidad, así como no tener en cuenta la mantenibilidad.

Ahora que hemos establecido que el propósito de las decoraciones de "esto es un miembro" ya no se cumple, ya que el alcance de la función debería ser demasiado pequeño y el alcance global no existe, hay una desventaja en esos marcadores: inhiben mover argumentos / variables locales a miembros, o al revés.

¿Por qué los desarrolladores evitan anteponer espacios de nombres con la directiva using namespace?

System.DateTime()es mucho más explícita que DateTime(). Me dice exactamente con qué estoy tratando. ¿Es solo porque somos mecanógrafos perezosos?

No. Somos mecanógrafos perezosos, pero esa no es la razón.

Preferimos los estilos de codificación que nos permiten ignorar los detalles y centrarnos en las abstracciones. Forzar nombres para comunicar detalles de la estructura es una distracción. Cuando estoy trabajando en un algoritmo complicado, no quiero nombres que insistan en recordarme cada pequeño detalle sobre la cosa con la que estoy trabajando. Solo necesito el nombre para evitar que me confunda Timery DateTime. Me preocuparé si son compatibles en otro lugar.

Es la misma razón por la que no quieres dos hombres en tu equipo llamados Jon. El hecho de que tengan apellidos no es una razón para darles prefijos o sufijos. Solo voy a llamarte Skeet. Cualquier cosa más es un dolor rotundo.

Vamos a expandirnos un poco.

Hay 3 estilos de prefijos comunes, todos los cuales se encuentran ocasionalmente en el código de C #:

• metro_
• _ _
• esta.

Tales prefijos se usan comúnmente en la implementación privada de una clase . La recomendación de Microsoft se refiere principalmente a las partes expuestas de una clase.

La ventaja de usar m_over _es que el prefijo puede ser el mismo en toda la base de código si usa c #, así como los lenguajes donde _no se permite usar como prefijo . * La ventaja de m_over this.es que es más corto y que no lo hará accidentalmente Olvídate del prefijo.

La ventaja de _over m_es que es más corto y que todo lo que comienza con el prefijo se ordena en la parte superior se ordena alfabéticamente por una herramienta. La ventaja de _Over this.es que es más corto y que no te olvidarás accidentalmente del prefijo.

La ventaja de this.over m_y _es que puede usarlo en una base de código donde _o m_no es una convención universal y aceptada. Eso también significa que las necesidades de nadie saber sobre el _o m_convención, que puede ser visto como hacer las cosas más simples. Como inconveniente, debido a que al compilador no le importa este prefijo, this.ocasionalmente faltará el prefijo y, como tal, no será tan confiable como un indicador.

* Una vez que comience a acceder a las clases de C # que usan _C ++ / CLI (que realmente no debería usar _), notará que acordar un prefijo común es más complejo de lo que debería ser. Decidir no tener un prefijo elimina ese ruido. Combine esto con la respuesta de Deduplicator, que parafrasearé como "la ventaja de un prefijo es casi insignificante", y nos da: "Hay un pequeño problema al usar prefijos, y una pequeña ventaja, por lo que es una opción válida para no usalos, usalos a ellos".

Hay una pregunta anterior sobre stackoverflow relacionada con esto.

Cabe señalar que la guía de estilo de MS solo habla sobre métodos y variables públicas y protegidas. es decir, los otros desarrolladores verán si usan tu biblioteca.

La idea es que las bibliotecas de Microsoft tengan un aspecto estándar para los desarrolladores que las consuman.

Puede usar el estilo que desee en sus variables privadas o locales.

Habiendo dicho eso, los prefijos variables se desaconsejan en general por varias razones

• Pueden estar equivocados y, por lo tanto, ser engañosos.
• Si está prefijando por tipo de variable, no está claro cómo maneja las clases que ha creado.
• Hay una serie de convenciones y no siempre están de acuerdo. Lo que encuentres útil, otro desarrollador puede encontrar inútil
• En el caso de las variables miembro, puede usar este 'esto'. palabra clave para indicar el alcance y el cumplidor lo hará cumplir.

Para mí, si estoy leyendo el código de otra persona y veo esto:

count = 3;

Supongo que 'contar' es una variable local de esa función y estoy haciendo algo que se usará en otra parte de la función

Y tendrá toda la razón si está leyendo el código fuente que respeta las convenciones de estilo de C #. En tal código:

this.count = 3;

asigna un valor a un campo.

count = 3;

asigna un valor a una variable local.

Por lo tanto, las convenciones de estilo de C # son claras e inequívocas. Te obligan a no usar ningún prefijo simplemente porque no necesitas uno.

En cuanto al código fuente para que los autores decidieron utilizar sus convenciones personales en su lugar, usted debe preguntar a ellos personalmente por qué tomó la decisión de hacerlo. Si no usan prefijos tales como guiones bajos, mientras que no usan this.ninguno, conduciría efectivamente no solo a un código difícil de leer, sino también a casos en los que se necesitaría una convención adicional:

public class Hello
{
    private string greetings;

    public Hello(string greetings)
    {
        greetings = greetings; // Wait, what is that?!
    }
}

¿C # no tiene esta palabra clave? ¿No podría referirse a los miembros que usan esto, como this.count?

Sí, pero (1) es más mecanografía y (2) es fácil de olvidar. Si el campo se llama m_count, no tengo que recordar escribir esto.m_count

Aquí, sin embargo, te equivocas.

Es más escribiendo cuando escribe su código en el Bloc de notas. Con un IDE con autocompletado o, mejor, IntelliSense, la comparación entre this.county m_countno es tan obvia. Tenga en cuenta el Shift+ -requerido para escribir el guión bajo.

En cuanto a "fácil de olvidar", nuevamente, esto es relevante solo para los usuarios de Notepad. No solo StyleCop y Resharper no te permitirán olvidar ponerlo this.cuando sea necesario, sino que después de unas horas de programación, ponerlo this.cuando sea necesario se convierte en un hábito.

El prefijo "miembro" es una especie de detalle de implementación. Desvía su atención del dominio del problema al dominio de la solución técnica que sesga su mente al pensar en posibles refactorizaciones. - yo

¿Puedes explicar más? La suya es la única razón por la que he visto por qué no usar el prefijo y no lo entiendo ... (lo que quiero decir, las otras cosas que la gente dice son razones por las que no tengo que usarlo, que no es lo mismo que por qué no debería) - Betty Crokker

Mi punto es extender las respuestas de @CandiedOrange y @Ewan.

Los prefijos dificultan la refactorización

A medida que su código evoluciona, las variables y los métodos pueden cambiar su alcance. P.ej. puede crear un método privado y luego descubrir que también debería estar disponible para otras (nuevas) clases. Similar puede suceder con los parámetros del método y las variables locales.

Supongamos que crea una calculadora de impuestos. De acuerdo con el principio del alcance de visibilidad del arrendamiento para las variables, comienza con un método que toma tanto la tasa impositiva como el valor base como parámetros:
^{(el ejemplo puede parecer Java-ish ...)}

class TaxCalculator{
   double Calculate(double p_TaxRateInpercent, double p_BaseValue){
     return (100+p_TaxRateInpercent)/100 * p_BaseValue;
   }
} 

a continuación, debe implementar la operación inversa y, según TDD, lo hace con el menor esfuerzo:

class TaxCalculator{
   double Calculate(double p_TaxRateInpercent, double p_BaseValue){
     return (100+p_TaxRateInpercent)/100 * p_BaseValue;
   }
   double CalculateBase(double p_TaxRateInpercent, double p_TaxedValue){
     return p_TaxedValue/((100+p_TaxRateInpercent)/100);
   }
} 

El siguiente TDD quiere que refactorice el código para que sea más limpio, lo que es reducir la lista de parámetros de ambos métodos.
^{(Sí, primero extraería el cálculo duplicado, pero permítame entender mi punto ...)}
La solución obvia es cambiar la tasa impositiva en una variable miembro pasándola como un parámetro constructor.

class TaxCalculator{
   double m_TaxRateInpercent;
   TaxCalculator(double p_TaxRateInpercent){
     m_TaxRateInpercent = p_TaxRateInpercent;
   }
   double Calculate(double p_BaseValue){
     return (100+m_TaxRateInpercent)/100 * p_BaseValue;
   }
   double CalculateBase(double p_TaxedValue){
     return p_TaxedValue/((100+m_TaxRateInpercent)/100);
   }
} 

Como puede ver, tuvimos que cambiar todas las líneas de nuestros métodos existentes (cualquier línea que solíamos p_TaxRateInpercentser exactas).

El problema es que no tiene soporte de su IDE para cambiar el nombre en toda la clase. La única ayuda es buscar / reemplazar, que también cambiará el constructor o cualquier parte que accidentalmente contenga la cadena p_TaxRateInpercent.
^{Su IDE podría ofrecer un cambio a ... refactorizar nombres de variables indefinidos, pero esto puede estar restringido al alcance del método}

Sin el prefijo, solo las firmas del método habrían cambiado. No se habría necesitado ningún cambio de nombre.

Prefija el historial de desorden SCM cuando se cambia

Además, el SCM registra el cambio del prefijo como cambios en la lógica, ¡aunque la lógica no cambió! La historia de SCM está abarrotada con este cambio técnico que oculta lo que es importante y aumenta el riesgo de conflictos con los cambios (lógicos reales) de otros.

Yo uso el prefijo _ para todas las variables miembro. Odio el prefijo 'this' porque, aunque algunos afirman que es la forma correcta de hacer las cosas, agrega mucho ruido / desorden a su base de código. Un solo guión bajo también es una práctica común en las muestras de Microsoft.

Entonces, en su ejemplo, tendría:

int _count = 10;