Convención de nomenclatura de C# para constantes?

En Realidad, es

private const int TheAnswer = 42;

Al menos si nos fijamos en la biblioteca.NET, que IMO es la mejor manera de decidir las convenciones de nombres - por lo que su código no se ve fuera de lugar.

Visualmente, Mayúsculas es el camino a seguir. Es tan reconocible de esa manera. Por el bien de la singularidad y sin dejar ninguna posibilidad de adivinar, voto por UPPER_CASE!

const int THE_ANSWER = 42;

Nota: La mayúscula será útil cuando se usen constantes dentro del mismo archivo en la parte superior de la página y para propósitos de intellisense; sin embargo, si se movieran a una clase independiente, usar Mayúsculas no haría mucha diferencia, por ejemplo:

public static class Constant
{
    public static readonly int Cons1 = 1;
    public static readonly int coNs2 = 2;
    public static readonly int cOns3 = 3;
    public static readonly int CONS4 = 4;
}

// Call constants from anywhere
// Since the class has a unique and recognizable name, Upper Case might might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }

Todavía voy con las mayúsculas para los valores const, pero esto es más por costumbre que por cualquier razón en particular.

Por supuesto que hace que sea fácil ver inmediatamente que algo es una const. La pregunta para mí es: ¿realmente necesitamos esta información? ¿Nos ayuda de alguna manera a evitar errores? Si le doy un valor a la const, el compilador me dirá que hice algo tonto.

Mi conclusión: Ir con la cubierta del camello. Tal vez voy a cambiar mi estilo también ;-)

Editar:

Que algo huele húngaro no es realmente un argumento válido, IMO. La pregunta siempre debe ser: ¿Ayuda o duele?

Hay casos en los que el húngaro ayuda. No muchos hoy en día, pero todavía existen.

Primero, la notación húngara es la práctica de usar un prefijo para mostrar el tipo de datos de un parámetro o el uso previsto. Las convenciones de nomenclatura de Microsoft para dice no a la Notación húngara http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

No se recomienda usar MAYÚSCULAS como se indica aquí: Pascal Case es la convención aceptable y SCREAMING CAPS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft también indica aquí que se puede usar MAYÚSCULAS si se hace para que coincida con el esquema existente. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

Esto lo resume bastante.

Deja el húngaro a los húngaros.

En el ejemplo incluso dejaría fuera el artículo definitivo y simplemente iría con

private const int Answer = 42;

¿Es esa la respuesta o es esa la respuesta?

*Hecho editar como Pascal estrictamente correcto, sin embargo, estaba pensando que la pregunta buscaba más una respuesta a la vida, el universo y todo.

En su artículo Constantes (Guía de programación en C#) , Microsoft da el siguiente ejemplo:

class Calendar3
{
    const int months = 12;
    const int weeks = 52;
    const int days = 365;

    const double daysPerWeek = (double) days / (double) weeks;
    const double daysPerMonth = (double) days / (double) months;
}

Entonces, para las constantes, aparece que Microsoft recomienda el uso de camelCasing. Pero tenga en cuenta que estas constantes se definen localmente.

Podría decirse que el nombramiento de constantes visibles externamente es de mayor interés. En la práctica, Microsoft documenta sus constantes públicas en la biblioteca de clases.NET como campos. He aquí algunos ejemplos:

• Int32.MaxValue
• Cadena.Vacío (en realidad, static readonly)
• Matemáticas.PI
• Matemáticas.E

Los dos primeros son ejemplos de PascalCasing. El tercero parece seguir las Convenciones de capitalización de Microsoft para un acrónimo de dos letras (aunque pi no es un acrónimo). Y el cuarto parece sugerir que la regla para un acrónimo de dos letras se extiende a una sola letra acrónimo o identificador como E (que representa la constante matemáticae).

Además, en su documento de Convenciones de Capitalización, Microsoft indica muy directamente que los identificadores de campo deben nombrarse a través de PascalCasing y da los siguientes ejemplos para MessageQueue.InfiniteTimeout y UInt32.Min :

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

Conclusión: Use PascalCasing para constantes públicas (que son documentados como campos const o static readonly).

Finalmente, por lo que sé, Microsoft no aboga por convenciones específicas de nomenclatura o capitalización para los identificadores privados como se muestra en los ejemplos presentados en la pregunta.

En realidad tiendo a preferir PascalCase aquí, pero por costumbre, soy culpable de UPPER_CASE...

El ALL_CAPS está tomado de la forma de C y C++ de trabajar creo. Este artículo aquí explica cómo se produjeron las diferencias de estilo.

En los nuevos IDE como Visual Studio es fácil identificar los tipos, el alcance y si son constantes por lo que no es estrictamente necesario.

El software FxCop y Microsoft StyleCop le ayudarán a darle pautas y verificar su código para que todos funcionen de la misma manera.