Convenzione di denominazione C # per le costanti?

Question

private const int THE_ANSWER = 42;

o

private const int theAnswer = 42;

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

Answer 1

La convenzione di denominazione e capitalizzazione raccomandata prevede l'uso dell'involucro Pascal per le costanti (Microsoft ha uno strumento chiamato StyleCop che documenta tutte le convenzioni preferite e possono verificare la conformità della tua fonte, anche se è un po ' troppo analmente ritentivo per i gusti di molte persone). per es.

private const int TheAnswer = 42;

La convenzione di capitalizzazione Pascal è anche documentata nel di Microsoft Linee guida per la progettazione .

Answer 2

In realtà, è

private const int TheAnswer = 42;

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

Answer 3

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 : le maiuscole saranno utili 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 might lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }

Answer 4

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

Ovviamente è 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: scegli l'involucro del cammello. Forse cambierò anche il mio stile ;-)

Modifica

Che qualcosa profuma 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.

Answer 5

In primo luogo, 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 per dire no alla notazione ungherese http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

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

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

Questo praticamente lo riassume.

Answer 6

Lascia l'ungherese agli ungheresi.

Nell'esempio tralascerei persino l'articolo definitivo e andrei semplicemente con

private const int Answer = 42;

È quella risposta o è quella la risposta?

* Fatto modifica come Pascal strettamente corretto, tuttavia stavo pensando che la domanda stesse cercando più di una risposta a vita, universo e tutto .

Answer 7

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, appare che Microsoft sta 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 (in realtà, statico in sola lettura )
• 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 è 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 sola lettera come E (che rappresenta la costante matematica e ).

Inoltre, nel suo documento sulle Convenzioni sulla capitalizzazione, Microsoft afferma direttamente che gli identificatori di campo dovrebbero essere nominati tramite PascalCasing e 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 PascalCasing per le costanti pubbliche (che sono documentate come const o campi statici di sola lettura ).

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

Answer 8

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

Answer 9

Credo che ALL_CAPS sia tratto dal modo di lavorare in C e C ++. Questo articolo qui spiega come le differenze di stile sono nate.

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

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