Convención de nomenclatura de variables en lenguaje de programación C # [cerrado]

Estoy viendo un video en C # sobre Variables. El autor declara una variable dentro de un método y la nombra así: string MyName = "James";

mi pregunta es: qué convención es recomendada por .Net Framework. ¿Es la carcasa de Pascal como en el ejemplo anterior o es un caso de camello?

c# coding-standards variables conventions

— Kaser
fuente

El problema con esta pregunta, que no sabías, así que no es tu culpa, es que de hecho no existe una convención canónica para C #. Hay convenciones comunes; desafortunadamente más de uno, pero sería bastante difícil para usted obtener una respuesta aquí que no sea pura opinión. Lo siento, votando para cerrar; mi sugerencia: Dedique un tiempo a leer el código en los repositorios populares de github y codeplex para ver qué convenciones usan como personas que escriben la mayoría de los populares que son personas con experiencia en la industria y tan canónicos como lo que encontrará.

— Jimmy Hoffa

Convenciones de nomenclatura de MSDN - msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx

— Yusubov

@Yusubov Estos describen los nombres de las partes públicas de las bibliotecas, no las variables locales.

— svick

Respuestas:

No creo que haya algo así como una convención 'oficial'. Hasta donde yo sé, muchos desarrolladores experimentados de C # consideran que lo siguiente es una buena práctica:

PascalCase for public member variables (string MyName = "James")

camelCase for local variables (string myName = "James")

_leadingUnderscore for private member variables (string _myName = "James")

Con este enfoque, se puede distinguir entre las variables locales y los miembros públicos y privados por el caso de su primera carta.

Como con cualquier convención de codificación, esto también está sujeto a preferencias personales. Por lo tanto, no hay una respuesta definitiva. Un objetivo general debe ser mantener el código lo más legible y comprensible posible.

— deslumbramiento
fuente

+1 Esto está cerca del estilo que he visto. Creo que generalmente se toma del estilo utilizado en los ejemplos de MSDN. Por lo general, veo propiedades obteniendo PascalCase, locales obteniendo camelCase, y miembros privados obteniendo a _leadingUnderscore.

— KChaloux

¿Te refieres a Campos o Propiedades cuando dijiste variables miembro?

— Kaser

Desarrolladores Delphi tienden a parámetros de función Nombre / método mediante un prefijo con una 'a': (aParameter: string). Me doy cuenta de que los parámetros son esencialmente variables locales, especialmente cuando se pasan por valor, pero a menudo es muy útil "ver" que una var realmente se pasa como parámetro. ¿Existe alguna convención en C #?

— Marjan Venema

Y otro: campos de miembros. Los delfos los prefieren con una 'F'. He visto el código C # que los declara con un guión: private string _SomeString. ¿Dirías que es una convención? (Solo sumerjo los dedos de los pies en C # y me pregunto sobre estas cosas).

— Marjan Venema

Esto es inexacto. Existen convenciones de nomenclatura publicadas para miembros públicos (y clases públicas, etc.).

— svick

Las convenciones de nomenclatura de .Net Framework ( v4.5 , v1.1 ) son agnósticas al respecto. No especifican un estándar para nombrar variables locales. Tendrás que decidir tu propia convención para nombrarlos.

Personalmente uso camelCase, y desambiguo las variables miembro de los nombres de los parámetros thiscuando es necesario. Pero los guiones bajos principales (es decir _memberVariable) también son válidos.

— Robert Harvey
fuente

Esta es exactamente la razón de usar convenciones de nomenclatura: usar thispara distinguir variables locales de campos / propiedades. 5 letras adicionales cada vez es demasiado en mi humilde opinión.

— Sinatr