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

Hice esta pregunta hace bastante tiempo: ¿Cómo nombras tus variables privadas en C #?

En una de las respuestas, me señalaron la página de MSDN de Microsoft que muestra que las variables / campos privados deberían llamarse así:

private int myInteger;

Pero un parámetro sería:

void SomeMethod(int myInteger)

y una variable local sería así:

int myInteger;

Entonces, cuando los mencionas así

myInteger = 10;

no tienes forma de saber de qué estás hablando.

Ahora estoy comenzando un nuevo proyecto y uno de mis compañeros de trabajo me pregunta por qué no hacemos algo para diferenciar al menos algunos de estos.

Me estoy preguntando lo mismo. ¿Por qué el estándar de Microsoft no los mantuvo diferentes?

Las convenciones de nomenclatura originales tenían un prefijo m_ para los miembros de la clase, esto se redujo a un simple guión bajo. Verá muchos códigos C # de Microsoft más antiguos utilizando un prefijo de subrayado. Sin embargo, escuché en un Tech Ed una vez que un guión bajo destacado no es compatible con CLS. Supongo que esta es la razón por la que se trasladaron al esquema más simple de un nombre para todos. Solía ​​ser (no estoy seguro ahora) que los nombres insensibles a mayúsculas y minúsculas de VB.Net tampoco eran compatibles con CLS.

Por lo que vale, todavía uso el guión bajo principal para los miembros de la clase. A pesar de que puede desambiguar el uso de esto (this.name en lugar de name), los errores aún pasan.

No tiene que hacer todo lo que MS le dice que haga.

localy las parametervariables se nombran de la misma manera porque su alcance es el mismo

En cuanto a las variables privadas, hay diferentes opiniones al respecto. Siempre he usado los estándares que se encuentran aquí , que especifican el uso de un líder _antes de las variables privadas, aunque el autor dice que _es un poco controvertido y que Microsoft recomienda no hacerlo.

Wikipedia dice que en C y C ++

Los nombres que comienzan con un guión bajo doble o un guión bajo y una letra mayúscula están reservados para la implementación (compilador, biblioteca estándar) y no deben usarse (por ejemplo, __reserved o _Reserved).

quizás esa fue la razón por la que Microsoft recomendó eso, aunque es bastante conocido que muchos desarrolladores de Microsoft usan un _prefijo para sus variables privadas de todos modos.

No puedo decirte con certeza por qué no los mantuvieron diferentes. Es probable que nadie pueda a menos que alguien que participó en la creación de los estándares vea esta pregunta.

Muchas personas crean sus propias convenciones al prefijar las variables de instancia con _o m_, pero realmente no creo que importe. Puede inferir mucho del contexto y los IDE en estos días son lo suficientemente inteligentes como para ayudarlo. Visual Studio con el complemento ReSharper, por ejemplo, le mostrará variables locales y variables de instancia en diferentes colores.

Si realmente importa que diferencie entre los dos ámbitos, puede usar el this.prefijo para referirse a la variable de instancia:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Sin ningún otro complemento, Visual Studio lo ayudará de manera predeterminada con Intellisense:

(La ventana emergente aún puede ser diseñada por ReSharper allí, pero ReSharper no agrega nada a las características de Intellisense incorporado, por lo que si bien la acción puede verse un poco diferente, todavía tendrá ambas opciones allí. )

También puede usar herramientas de análisis de código como FxCop y StyleCop para ayudarlo a detectar posibles problemas con el nombre y el alcance de las variables.

¿Por qué el estándar de Microsoft no los mantuvo diferentes?

La gente de Microsoft escribió un libro llamado Framework Design Guidelines que explicaba una serie de convenciones, incluido por qué algunas cosas estaban en camello y otras en pascal .

Editar (agregando detalles del libro):

En el libro, mencionan hacer estudios de usabilidad, así como algunas de las lecciones aprendidas de la adquisición del grupo Turbo Pascal. Además, aunque no todos los lenguajes distinguen entre mayúsculas y minúsculas (como VB), otros sí lo son (como C #), por lo que uno debe ser coherente en el nombre. No se puede depender de las diferencias solo para distinguir los elementos. Si uno se apega a las convenciones utilizadas por el resto del marco, dará lugar a menos confusión por parte de los desarrolladores.

Capítulo 3, Pautas de nomenclatura.
La Sección 3.1 es las convenciones de capitalización.

camelCasinges para nombres de parámetros.
PascalCasinges para espacios de nombres, tipos y nombres de miembros. En el caso de que haya acrónimos de 2 letras como parte del nombre, manténgalos en mayúsculas juntos, como IOStream.

La Sección 3.5 cubre las clases de nombres, estructuras e interfaces.
La sección 3.6 cubre los nombres de los miembros de tipo.
La sección 3.7 cubre los parámetros de nomenclatura.

Porque son bastante distinguibles ya que dependen del contexto en el que están escritos.

Por ejemplo, ¿alguna vez ha usado un parámetro como variable miembro? ¿O una variable local como parámetro? ¿Qué tal una variable miembro como local?

• Todas las variables miembro están en el "cuerpo" de una clase. Realmente no compro el argumento de que necesita prefijar el miembro cuando puede usarlo thispara distinguirlo de una variable local con un nombre similar, de lo contrario no es necesario.

• Una variable local también solo se define dentro del alcance de un método o dentro del alcance del bloque de código.

• Un parámetro siempre se define en la firma del método.

Si confunde o mezcla todos estos tipos de variables, entonces realmente debería pensar más en el diseño de su código para hacerlo más legible o reconocible. Dales nombres mejores y más descriptivos que myInteger.

No puedo responder su pregunta sobre los estándares de Microsoft. Si quieres un estándar para diferenciar estas cosas, el uso estándar de E para los parámetros de PL / SQL es un prefijo al nombre del parámetro con in_, out_, io_, para los parámetros in-, ambulatorios, y en ambulatorios. Las variables que son locales a una función tienen el prefijo a v_.

La mayoría de las compañías que conozco tienen estándares de codificación que especifican un guión bajo o la letra minúscula m (para "miembro", supongo) como prefijo para sus variables miembro.

Entonces

_varName

o

mVarName

Tal como lo han señalado otras personas, generalmente puede saber cuál es cuál, según el alcance, se utiliza el elemento. En realidad, no puede tener el parámetro y la variable local en el mismo ámbito y si desea la variable privada, simplemente use this.myInteger. Por lo tanto, no creo que Microsoft se haya preocupado demasiado, ya que puede diferenciarlos fácilmente si lo desea.

Pero dicho esto, estoy un poco sorprendido de que nadie haya dicho esto todavía, pero olvídate de Microsoft y sus convenciones de nomenclatura (bueno, alguien podría haberlo dicho por ahora, ya que tuve que correr a una reunión y dejar esto abierto sin enviarlo. eso). La notación húngara también fue una convención de nomenclatura iniciada en Microsoft (¿o fue Xerox? Nunca recuerdo cuándo se le ocurrió a Simonyi). No puedo pensar en nadie que conozca que no maldiga el nombre de la notación húngara hasta el día de hoy. Nos molestó tanto en el lugar que trabajé que creamos nuestro propio estándar que utilizamos internamente. Tenía más sentido para nosotros y aceleró un poco nuestro trabajo (en realidad era bastante parecido a lo que Microsoft sugiere ahora, pero todo fue un caso pascal con la excepción de las variables privadas).

Dicho esto, el estándar más nuevo que usa Microsoft (la combinación de estuche de camello y estuche pascal) no es tan malo. Pero si a usted y a sus compañeros de trabajo no les gusta, invente sus propios estándares (colectivamente es lo mejor). Esto, por supuesto, depende de si su empresa ya tiene o no un conjunto de estándares. Si lo hacen, quédese con ellos. De lo contrario, invente lo que funciona para usted y sus compañeros de trabajo. Solo mantenlo lógico.

Desde que Aaronaught solicitó una cita sobre Charles Simonyi y la notación húngara: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Los dos últimos son solo ejemplos de notación húngara y el enlace de Ootips son solo algunas citas sobre algunas opiniones sobre el tema. Tenga en cuenta que también hay un sistema de notación húngara, pero que, hasta donde sé, llegó a ser popular entre los programadores de Microsoft (aunque, a diferencia de Simonyi para la variación de aplicaciones, no sé quién).