¿Convención de nomenclatura de C # para constantes?


420
private const int THE_ANSWER = 42;

o

private const int theAnswer = 42;

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


44
@mmiika: ¿cuál es el significado "el" en este ejemplo? ¿Es como en "The Hitchhiker's Guide to the Galaxy" o se transfiere de algún estándar de codificación C ++? (Por ejemplo, un antiguo marco de trabajo de C ++ para Macintosh, THINK C [y más tarde, Symantec C ++], usaba el prefijo "its" para los miembros de puntero / referencia y "the" para los miembros escalares.)
Peter Mortensen

55
@Peter, dado que el valor de la constante es 42, creo firmemente que es una referencia a la Guía del autoestopista galáctico .
Albireo

@PeterMortensen ¡Eso es creativo! Pero nombres como itsEmployee y itsCostumer suenan como si pudieran ser engañosos.
Camilo Martin


Yo prefiero theAnswer. Anteriormente he sido un fanático de la notación húngara, pero desde que aprendí a no usarlo, me encanta evitar estrictamente cualquier metaindicación en la denominación. Lo mismo ocurre con las interfaces como IInterface. Yo prefiero Interfacable. Pero cuando trabajaba en un equipo, tenía que cumplir con las reglas :(
nawfal

Respuestas:


485

La nomenclatura recomendada y la convención de capitalización es el uso de P Ascal C Asing para constantes (Microsoft tiene una herramienta llamada StyleCop que documenta todas las convenciones preferidos y puede comprobar su fuente para el cumplimiento - aunque es un poco demasiado anal retentiva para el gusto de muchas personas) . p.ej

private const int TheAnswer = 42;

La convención de capitalización de Pascal también está documentada en las Pautas de diseño del marco de Microsoft .


51
En realidad, StyleCop "no es un producto de Microsoft", sino "una herramienta desarrollada por un desarrollador muy apasionado de Microsoft (en las noches y fines de semana)". (Consulte blogs.msdn.com/sourceanalysis/archive/2008/07/20/… y blogs.msdn.com/bharry/archive/2008/07/19/… ) para más detalles.) Dicho esto, el nombre del marco de Microsoft convenciones utilizan carcasa Pascal para las constantes, por lo que la herramienta se acaba de cumplir la norma de que Microsoft no publicar y aprueba.
bdukes

12
@bdukes: no dije que era un producto de Microsoft, sin embargo, tiene bastante uso y soporte en toda la organización (como ex empleado, lo estaba usando años antes de que alguien fuera de Microsoft lo tuviera en sus manos, así que Soy muy consciente de su herencia).
Greg Beech el

8
No me gusta esto, porque la primera letra se usa generalmente para indicar si una variable es externamente visible o no. En el código, TheAnswer parece una propiedad pública, no una constante privada para mí. En realidad, preferiría ir con un prefijo como constTheAnswer y ConstTheAnswer.
Efrain

52
Iría con la notación TheAnswer excepto cuando el valor sea 42, en cuyo caso definitivamente me quedaría con el enfoque ALL_CAPS.
Benoittr

44
¿No debería un campo privado estar en camello, evento si es constante?
Markus Meyer

70

Visualmente, Upper Case es el camino a seguir. Es tan reconocible de esa manera. En aras 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 con fines de inteligencia; sin embargo, si fueran trasladados 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 lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }

55
Yo también prefiero esto, ya que la carcasa Pascal se puede confundir fácilmente con una referencia de propiedad.
bc3tech

8
Independientemente de las recomendaciones anteriores, también prefiero la UPPER_CASE para constantes, ya que las hace mucho más fáciles de identificar en comparación con cualquiera de los otros casos.
doblaje el

23
@usefulBee "SNAKE_CASE" no se recomienda en C #; Esta respuesta es incorrecta. El caso correcto para consts en C # es "TitleCase".
BrainSlugs83

13
@ BrainSlugs83, no creo que haya algo correcto o incorrecto aquí; todo se reduce a preferencias y lo que hace que el código sea más claro.
ÚtilBee

2
@usefulBee De acuerdo. Pero aún así es bueno marcar cuál es la forma consensuada de escribirlo. He estado haciendo un montón de código Ruby últimamente, y creo que SCREAMING_SNAKE_CASE tiene sentido: es muy obvio que es algo especial, y ni siquiera necesitas desplazarte / Ir a la definición para averiguar de qué se trata. Lo sabes de inmediato.
Según Lundberg,

69

En realidad es

private const int TheAnswer = 42;

Al menos si observa la biblioteca .NET, qué IMO es la mejor manera de decidir las convenciones de nomenclatura, para que su código no se vea fuera de lugar.


23

Todavía uso mayúsculas para los valores constantes, 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 asigno un valor a la constante, el compilador me dirá que hice algo tonto.

Mi conclusión: ve con la tripa del camello. Quizás también cambie mi estilo ;-)

Editar:

Que algo huele húngaro no es realmente un argumento válido, en mi opinión. La pregunta siempre debe ser: ¿ayuda o duele?

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


30
El código se lee con mucha más frecuencia de lo que se escribe. Claro, cuando está escribiendo el código, el compilador le impedirá asignar a una constante. Pero, ¿qué pasa con el tipo que tiene que mantener su código dentro de dos años? Es seguro poder reconocer una constante de inmediato.
Greg Hewgill

2
Los IDE de hoy detectan muchos problemas antes de la compilación. No creo que sea importante reconocer constante por nombre, de lo contrario, ¿no debería agregar también un nombre especial para las variables de solo lectura?
mmiika

55
Si lo piensas bien, el habbit en mayúsculas probablemente provenía de macros de preprocesador en lugar de constantes (nunca he usado mayúsculas de bloque para constantes verdaderas). En ese contexto, tiene sentido distinguir las macros del código real porque una macro puede ser una expresión y no un valor constante, su expansión puede causar efectos secundarios, etc. Entonces necesita saber cuándo está usando una macro y cuándo está usando una constante. Personalmente me alegra ver la parte posterior de las macros de preprocesador, tenían mucho potencial para dificultar la lectura del código.
Tim Long,

77
@Tim: Estoy de acuerdo, al final las macros del preprocesador trajeron más daño que bien. Mi macro PP favorita: "#DEFINE Private Public" ;-)
Treb

1
@Tim: la biblioteca de plantillas estándar de C ++ ha adoptado minúsculas para constantes, por ejemplo, std :: string :: npos ( cplusplus.com/reference/string/string/npos ). Entonces ALL_CAPS es solo para macros y directivas de preprocesador, lo que hace que se vea aún más estúpido en C #.
Richard Dingwall el

16

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 decir 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í: Pascal Case es la convención aceptable y GRITOS. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

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

Esto prácticamente lo resume.


3
Sí, la notación húngara no es todo en mayúsculas.
snibbets

13

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, parece 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 externamente visibles 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 unos ejemplos:

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 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 PascalCasingy 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: Uso PascalCasingpara constantes públicas (que están documentadas como consto static readonlycampos).

Finalmente, hasta donde yo sé, Microsoft no recomienda convenciones específicas de nomenclatura o capitalización para identificadores privados como se muestra en los ejemplos presentados en la pregunta.


El desarrollador que escribió ese artículo claramente no estaba siguiendo las convenciones de estilo recomendadas por Microsoft para C #.
BrainSlugs83

2
El artículo señalado por esta respuesta ha cambiado. Los concursos ahora son públicos y han sido PascalCased. Dados ambos cambios, esto no ayuda a responder si las constantes privadas deben ser PascalCased o camelCased.
Metalogic

12

Deja húngaro a los húngaros.

En el ejemplo, incluso dejaría de lado el artículo definitivo y simplemente iría con

private const int Answer = 42;

¿Es esa respuesta o es la respuesta?

* Realicé la edición como Pascal estrictamente correcta, sin embargo, pensé que la pregunta buscaba más una respuesta a la vida, el universo y todo .


2
En este caso específico es la respuesta. Pero solo porque me gusta mucho leer D. Adams.
Treb

si, pero cual es la pregunta? y no me den de comer lo siento por la línea de inconvenientes;)
paloma

2
Ah, pero como ya sabes la respuesta, no puedes saber la pregunta. Son mutuamente excluyentes. (Apuesto a que ya lo sabías ;-)
Treb

Esta es la respuesta correcta a la pregunta del OP. - Te votaré dos veces por eliminar el Thesi pudiera. :-)
BrainSlugs83

¿Quién es húngaro? ¿Esta respuesta dice que se les permite usar la otra convención?
Capitán Prinny

6

De hecho, tiendo a preferir PascalCase aquí, pero por costumbre, soy culpable de UPPER_CASE ...


6

ALL_CAPS se toma de la forma de trabajo 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 software FxCop y Microsoft StyleCop lo ayudará a darle pautas y verificar su código para que todos trabajen de la misma manera.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.