programar - En las convenciones de nomenclatura de C#para variables miembro
notacion hungara para c# (14)
Cualquiera que sea la convención de nombres que elija, sea consistente. Entonces, al menos cuando vuelva al código dentro de seis meses, o cuando alguien lo vea por primera vez, podrá averiguar qué es qué.
He visto un consejo en alguna parte aquí sobre SO para no nombrar variables de miembro private/public , de manera que difieran solo en el caso del primer carácter. Por ejemplo:
private string logFileName;
public string LogFileName
{
get
{
return logFilename
....
y: private System.Windows.Forms.MainMenu mainMenu;
y: DialogResult dialogResult = this.saveConfigFileDialog.ShowDialog();
y:
public Version Version
{
get;
set;
}
y:
private void CheckPollingType(PollingType pollingType)
{
Entonces, ¿escuché mal? ¿Hay algo malo con estas convenciones de nombramiento? Si es así, ¿cuáles son las mejores maneras de hacerlo? Los enlaces, las referencias son un plus.
Gracias.
Dado que esto aparece entre los resultados de búsqueda más importantes con respecto al tema, también quería compartir mi sugerencia:
Además de la convención de Pascal / camelCase para miembros públicos / privados, siempre elijo nombres de variables de miembros que constan de 2 o más palabras , y nombres de variables locales que consisten en una sola palabra en minúscula o solo una letra.
public class MyCanvas : Canvas {
public int CanvasId { get; private set; }
private double canvasHeight; // member vars consist of 2+ words
private double canvasWidth;
public MyCanvas(int id) {
CanvasId = id;
double height = ...; // local vars consist of one word/letter
canvasHeight = height;
}
}
Esto permite elegir nombres de variables coherentes y significativos, sin prefijos "divertidos" como _ , pero también para distinguir entre variables locales y miembros.
Definitivamente es una convención de nombres muy popular y no veo por qué debería estar en contra.
Simplemente recomendaría seguir las convenciones de nomenclatura para C # provistas por MSDN y también las convenciones generales de nomenclatura provistas por MSDN .
Específicamente tienen esto que decir sobre las propiedades:
Nombre las propiedades usando un sustantivo, una frase nominal o un adjetivo.
Las frases nominativas o los adjetivos son apropiados para las propiedades porque las propiedades contienen datos.
No utilice propiedades que coincidan con los nombres de los métodos Get.
Por ejemplo, no asigne un nombre a la propiedad EmployeeRecord y también el nombre a un método GetEmployeeRecord. Los desarrolladores no sabrán qué miembro usar para realizar su tarea de programación.
Nombre las propiedades booleanas con una frase afirmativa (CanSeek en lugar de CantSeek). Opcionalmente, también puede prefijar propiedades booleanas con Is, Can o Has, pero solo donde agrega valor.
Considere dar a una propiedad el mismo nombre que su tipo.
Cuando tiene una propiedad que está fuertemente tipada en una enumeración, el nombre de la propiedad puede ser el mismo que el de la enumeración. Por ejemplo, si tiene una enumeración llamada CacheLevel, una propiedad que devuelve uno de sus valores también se puede llamar CacheLevel.
Creo que si hubiera una razón convincente para estar en contra de lo que está sugiriendo, lo habrían mencionado en sus pautas.
El problema básico con la convención de nomenclatura propuesta es que Intellisense usará la variable privada sobre la propiedad. En muchos casos, eso no es realmente un problema (es, de hecho, generalmente algo bueno), pero para los pocos casos en que lo es, es útil una convención que separa los dos nombres. Me gusta m_ para variables miembro privadas y c_ para variables estáticas privadas.
El problema principal con el mismo nombre con un caso diferente, es que no todos los idiomas en .net distinguen entre mayúsculas y minúsculas, es decir, Visual Basic.
El único escenario en el que ese es un problema real es cuando se exponen miembros públicos que solo varían según el caso. Hay un atributo de compatibilidad que se puede establecer, por lo que el compilador le dice si tiene uno de estos escenarios.
Lo dicho anteriormente, esto no afecta realmente el escenario del miembro privado de respaldo.
La mayoría de las variables de nivel de clase de tiempo se añaden con un guión bajo. Así que myVariable es en realidad _myVariable. A mucha gente no le gusta competir con el nombre de un personaje, porque es muy fácil cometer un error.
No hay nada de malo en hacer solo myVariable y MyVariable. Es solo una convención, y si todos lo siguen, entonces probablemente funcionará bien.
Personalmente, si es posible, prescindo de la variable privada y solo uso los captadores y definidores en la propiedad. La mayoría de las veces (pero no todo el tiempo), el acceso a la variable privada se utilizaba para no permitir el acceso de escritura en la propiedad.
Esto puede ser resuelto por:
public String MyVariable
{
get;
private set;
}
Lanzaré mi sombrero en el ring con lo que siempre he usado.
class ClassName //Classes are PascalCase
{
public ClassName(int myProperty) //Constructor arguments are named the same as the property they set but use camelCase.
{
_myProperty = myPropriety;
}
public void MyFunction(object varToBePassed) //Function names are PascalCase, passed pramaters are camelCase.
{
int sampleVar; //local variables are camelCase
}
public int MyProperty { get { return _myProperty; } } // Properties are PascalCase
private int _myProperty; // Private fields are camelCase and start with a _
Las dos convenciones más populares que veo están prefijando las variables de miembros privados con _ o m_. Personalmente prefiero la convención m_, pero siempre que sea consistente en todo el proyecto / equipo, realmente no me importa. No soy uno para entrar en ''guerras religiosas'' :)
No, no hay nada de malo en estas convenciones de nombres.
La versión de la propiedad es en realidad el formato recomendado de acuerdo con las pautas de diseño del marco .Net.
La declaración de campo también se ajusta a las directrices marco, ya que está en camello. Ocasionalmente es una guerra religiosa en cuanto a si la variable debe tener el prefijo _ o m_ . Sin embargo, esa es una pregunta que debe resolverse dentro de su grupo.
Pautas de diseño de .Net framework para miembros tipo
Por lo general, siempre veo miembros privados con un _. (asumiendo que no es una propiedad de auto)
private string _customerName;
public string CustomerName
{
get{return _customerName;}
set{_customerName = value;}
}
Por supuesto, el veredicto final es la convención de tu equipo (asumiendo que no estás haciendo un proyecto de lobo solitario o trabajando con idiotas absolutos)
Si solo estás haciendo C #, no hay problema, pero si tú (o tu equipo / compañía) también están haciendo VB.Net (que no distingue entre mayúsculas y minúsculas), entonces te recomiendo que sea mejor que no lo hagas en C # tampoco para que las convenciones de nombres entre diferentes idiomas no difieran demasiado.
Tenga cuidado con este escenario sin embargo:
public class MyClass {
public int Foo { get; private set; }
public MyClass(int foo) {
// oops, setting the parameter to itself, not the property
foo = foo;
}
}
Visual Studio le advertirá sobre esta situación, pero no es ilegal y puede deslizarse a veces.
Una razón por la que puedo pensar en no usar mayúsculas y minúsculas para diferenciar los miembros públicos frente a los privados es que Visual Studio Intellisense ordenará a los dos miembros uno al lado del otro, por lo que puede usar el incorrecto sin darse cuenta.
Dicho esto, utilizo la convención que describiste (usando el caso para diferenciar la accesibilidad) en mi código, y no he tenido ningún problema.