Convenzione di denominazione C # per le costanti?

private const int THE_ANSWER = 42;

o

private const int theAnswer = 42;

Personalmente penso che con gli IDE moderni dovremmo andare con camelCase dato che ALL_CAPS sembra strano. Cosa ne pensi?

La denominazione consigliata e la convenzione capitalizzazione è quello di utilizzare P Ascal C Asing per le costanti (Microsoft ha uno strumento chiamato StyleCop che documenti tutte le convenzioni privilegiate e possono controllare la vostra fonte per il rispetto - anche se è un po ' troppo anale a ritenzione per i gusti di molte persone) . per esempio

private const int TheAnswer = 42;

La convenzione di capitalizzazione Pascal è inoltre documentata nelle Linee guida per la progettazione di framework di Microsoft .

Visivamente, maiuscolo è la strada da percorrere. È così riconoscibile in quel modo. Per motivi di unicità e di non lasciare alcuna possibilità di indovinare, voto per UPPER_CASE!

const int THE_ANSWER = 42;

Nota : il maiuscolo sarà utile quando le costanti devono essere utilizzate all'interno dello stesso file nella parte superiore della pagina e per scopi di intellisense; tuttavia, se dovessero essere spostati in una classe indipendente, l'uso di Maiuscole non farebbe molta differenza, ad esempio:

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;
 }

In realtà lo è

private const int TheAnswer = 42;

Almeno se guardi la libreria .NET, quale IMO è il modo migliore per decidere le convenzioni di denominazione, quindi il tuo codice non sembra fuori posto.

Vado ancora con le maiuscole per i valori const, ma questo è più per abitudine che per qualsiasi motivo particolare.

Naturalmente è facile vedere immediatamente che qualcosa è una const. La domanda per me è: abbiamo davvero bisogno di queste informazioni? Ci aiuta in qualche modo a evitare errori? Se assegno un valore alla const, il compilatore mi dirà che ho fatto qualcosa di stupido.

La mia conclusione: vai con l'involucro del cammello. Forse cambierò anche il mio stile ;-)

Modificare:

Che qualcosa che profuma di ungherese non è in realtà un argomento valido, IMO. La domanda dovrebbe sempre essere: aiuta o fa male?

Ci sono casi in cui l'ungherese aiuta. Non così tanti al giorno d'oggi, ma esistono ancora.

Innanzitutto, la notazione ungherese è la pratica di utilizzare un prefisso per visualizzare il tipo di dati di un parametro o l'uso previsto. Le convenzioni di denominazione di Microsoft dicono no alla Notazione ungherese http://it.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

L'uso di MAIUSCOLO non è incoraggiato come indicato qui: Pascal Case è la convenzione accettabile e CAPPELLINI SCREAMING. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft afferma inoltre che MAIUSCOLO può essere utilizzato se viene eseguito per abbinare lo schema esistente. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

Questo lo riassume abbastanza bene.

Nel suo articolo Costanti (Guida per programmatori C #) , Microsoft fornisce il seguente esempio:

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;
}

Quindi, per le costanti, sembra che Microsoft stia raccomandando l'uso di camelCasing. Ma nota che queste costanti sono definite localmente .

Probabilmente, la denominazione di costanti visibili esternamente è di maggiore interesse. In pratica, Microsoft documenta le sue costanti pubbliche nella libreria di classi .NET come campi . Ecco alcuni esempi:

• Int32.MaxValue
• String.Empty (effettivamente, static readonly)
• Math.PI
• Math.E

I primi due sono esempi di PascalCasing. Il terzo sembra seguire le Convenzioni di capitalizzazione di Microsoft per un acronimo di due lettere (sebbene pi non sia un acryonym). E la quarta sembra suggerire che la regola per un acryonym di due lettere si estende ad un acronimo o identificatore di una singola lettera come E(che rappresenta la costante matematica e ).

Inoltre, nel suo documento sulle convenzioni di capitalizzazione, Microsoft afferma direttamente che gli identificatori di campo devono essere nominati tramite PascalCasinge fornisce i seguenti esempi per MessageQueue.InfiniteTimeout e UInt32.Min :

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

Conclusione: utilizzare PascalCasingper costanti pubbliche (che sono documentate come constostatic readonly campi).

Infine, per quanto ne so, Microsoft non sostiene convenzioni specifiche di denominazione o capitalizzazione per identificatori privati, come mostrato negli esempi presentati nella domanda.

Lascia l'ungherese agli ungheresi.

Nell'esempio tralascerei persino l'articolo definitivo e vado avanti

private const int Answer = 42;

È quella risposta o è quella la risposta?

* Fatto modifica come Pascal rigorosamente corretto, tuttavia pensavo che la domanda fosse più una risposta alla vita, all'universo e tutto .

In realtà tendo a preferire PascalCase qui - ma per abitudine, sono colpevole di UPPER_CASE ...

Credo che ALL_CAPS sia tratto dal modo di lavorare C e C ++. In questo articolo qui spiega come le differenze di stile venuto circa.

Nei nuovi IDE come Visual Studio è facile identificare i tipi, l'ambito e se sono costanti, quindi non è strettamente necessario.

Il software FxCop e Microsoft StyleCop ti aiuteranno a fornire linee guida e controllare il tuo codice in modo che tutti lavorino allo stesso modo.