Pascal o caja de camello?Private Static Readonly Field Capitalization
Indico campos privados y campos estáticos privados usando camel case. Yo nombro consts (como lo sugieren las convenciones de nomenclatura de MS) con el caso pascal (independientemente de privado vs. público) ....
¿Y qué pasa con el static static readonly? La lógica dice que es un estuche de camello ... pero una lectura estática privada es funcionalmente como una const ... ¿verdad?
hace uso de carcasa Pascal en nombres de campo ...
Las instrucciones de nomenclatura para los campos aplican a los campos públicos y protegidos estáticas. No debe definir campos de instancia públicos o protegidos.
Campo de sólo lectura estática = Pascal
MSDN Official Naming Convention
Reglas Generales:
Utilizar Pascal carcasa para miembro público, tipo y nombres de espacio de nombres que consta de varias palabras.
Tenga en cuenta que esta regla no se aplica a los campos de instancia . Por razones que son detalladas en las Directrices de , , no debe usar los campos de instancia públicos .
Use camel case para el parámetro nombres.
Lista completa:
IDENTIFIER CASE EXAMPLE ----------------------+-----------+--------------- Class Pascal AppDomain Enumeration types Pascal ErrorLevel Enumeration values Pascal FatalError Event Pascal ValueChanged Exception class Pascal WebException Read-only static field Pascal RedValue Interface Pascal IDisposable Method Pascal ToString Namespace Pascal System.Drawing Parameter Camel typeName Property Pascal BackColor
MSDN Official Naming Convention
Considera también
Esta lista no cubre los miembros * privados * ni los campos que no son de solo lectura y estáticos. – cdhowie
Esta lista dice lo contrario. El único listado aquí que tiene un alcance obviamente restringido es * parámetro *. Por eso es Camel. el enlace lo lleva a "Convenciones de capitalización" que menciona que Pascal se aplica a los miembros * públicos *. –
@cdhowie: Buen punto y he actualizado mi respuesta para cubrir campos públicos y estáticos. –
No, private static readonly no es en sí mismo como const en absoluto. Considere:
private static readonly IList<int> foo = new List<int>();
Todavía puede hacer foo.Add(0);. Dichos campos son solo de tipo const cuando el objeto en sí mismo, así como cualquier objeto referenciado, son inmutables.
No me preocuparía la coincidencia de las convenciones de los demás: siempre que sea coherente con la convención de nomenclatura que utilice, realmente no importa lo que elija hacer. Hay cosas mucho más importantes de las que preocuparse.
Sin embargo, es conveniente que otras personas tomen estas decisiones por usted, ya que son bastante intrascendentes. –
Es importante seguir las convenciones estándar. Imagínese si se muda a un nuevo proyecto y tiene que aprender a cumplir con las convenciones que le son ajenas. Imagine tratar de incorporar una biblioteca de terceros que tenga convenciones contrarias a las convenciones de su proyecto. Imagine una nueva contratación entrando e intentando hacer frente a los estándares de su convención interna patentada. Tengo que estar completamente en desacuerdo con esta respuesta: ** Por el contrario, es MUY importante seguir un conjunto estandarizado de convenciones aceptadas por la industria. ** No reinvente la rueda porque es demasiado perezoso para mirar hacia el camino correcto. – crush
que tiene una advertencia en StyleCop para:
private readonly Color LabelBackColor = Color.Black;
364 Advertencia SA1306: CSharp.Naming: nombres de las variables y los nombres de los campos privados deben comenzar con una letra minúscula: LabelBackColor.
Ver this discussion: campos de sólo lectura privadas deben comenzar con un carácter en minúscula. Esto significa caso Camel.
Aquí hay un ejemplo de fuente de referencia. Curiosamente, Microsoft utilizó aquí guiones bajos para campos privados y camelCase (sin subrayado) para lecturas estáticas privadas de http://referencesource.microsoft.com/#mscorlib/system/collections/arraylist.cs,3e3f6715773d6643. Pero este segundo ejemplo también muestra que Microsoft no tiene su propio estándar para nombres de campo: http://referencesource.microsoft.com/#mscorlib/system/collections/hashtable.cs
¿Por qué crees que es como una const? – Xaqron
Porque, en uso, el readonly estático privado es el mismo que el de un cosnt: establece una vez, no puede cambiar, el alcance estático. Me doy cuenta de que const tiene una implementación completamente diferente (ser compilado e interpretado y demás). – Jeff