¿C # convención de nomenclatura para constantes?

StackOverflow https://stackoverflow.com/questions/242534

  •  04-07-2019
  •  | 
  •  

Pregunta 

private const int THE_ANSWER = 42;

o 

private const int theAnswer = 42;

Personalmente creo que con los IDE modernos deberíamos ir con camelCase ya que ALL_CAPS parece extraño. ¿Qué piensas?

¿Fue útil?

Solución

La convención de uso de letras y mayúsculas recomendada es usar la carcasa de Pascal para constantes (Microsoft tiene una herramienta llamada StyleCop que documenta todas las convenciones preferidas y pueden verificar su fuente para el cumplimiento, aunque es un poco también analmente retentivo para los gustos de muchas personas). por ejemplo 

private const int TheAnswer = 42;

La convención de capitalización de Pascal también se documenta en Framework Pautas de diseño .

Otros consejos

En realidad, es 

private const int TheAnswer = 42;

Al menos si observa la biblioteca .NET, la IMO es la mejor manera de decidir las convenciones de nombres, por lo que su código no parece fuera de lugar.

Visualmente, mayúsculas es el camino a seguir. Es tan reconocible de esa manera. En aras de la singularidad y de no dejar ninguna posibilidad de adivinar, ¡voto por UPPER_CASE! 

const int THE_ANSWER = 42;

Nota : la letra mayúscula será útil cuando se usen constantes dentro del mismo archivo en la parte superior de la página y con propósitos de inteligencia. sin embargo, si se cambiaran a una clase independiente, el uso de mayúsculas no haría mucha diferencia, como 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;
 }

Sigo con mayúsculas para los valores const, pero esto es más por costumbre que por alguna razón en particular.

Por supuesto, hace que sea fácil ver de inmediato que algo es una constante. La pregunta para mí es: ¿Realmente necesitamos esta información? ¿Nos ayuda de alguna manera a evitar errores? Si le asigno un valor a la constante, el compilador me dirá que hice algo estúpido.

Mi conclusión: Ir con la carcasa de camello. Tal vez yo también cambie mi estilo ;-)

Editar:

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

Hay casos en que el húngaro ayuda. No tantos 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. 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 el uso de MAYÚSCULAS como se indica aquí: El caso de Pascal es la convención aceptable y CAPAS DE GANAR. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft también afirma aquí que se puede utilizar 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 bien.

Deja el húngaro a los húngaros.

En el ejemplo, incluso omitiría el artículo definitivo y simplemente iría con 

private const int Answer = 42;

¿Es esa respuesta o es esa la respuesta?

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

En su artículo Constantes (Guía de programación de 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 constantes, aparece que Microsoft recomienda el uso de camelCasing . Pero tenga en cuenta que estas constantes se definen localmente .

Podría decirse que la denominación 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 . Aquí hay algunos ejemplos:

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

Además, en su documento de Convenciones de Capitalización, Microsoft establece muy directamente que los identificadores de campo deben nombrarse a través de PascalCasing y proporciona 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 las constantes públicas (que se documentan como campos const o de lectura estática ).

Finalmente, hasta donde sé, Microsoft no aboga por convenciones específicas de uso de nombres o uso de mayúsculas 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 trabajar de C y C ++, creo. Este artículo aquí explica cómo surgieron 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 FxCop y Microsoft StyleCop le ayudará a darle pautas y verificar su código para que todos trabajen de la misma manera.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top