Konwencja nazewnictwa C # dla stałych?

Właściwie to jest

private const int TheAnswer = 42;

Przynajmniej jeśli spojrzysz na bibliotekę. NET, która IMO jest najlepszym sposobem decydowania o konwencjach nazewnictwa - aby Twój kod nie wyglądał nie na miejscu.

Wizualnie Wielkie Litery to najlepszy sposób. Jest tak rozpoznawalny. Ze względu na wyjątkowość i brak szans na zgadywanie, Głosuję na UPPER_CASE!

const int THE_ANSWER = 42;

Notatka: wielkie litery będą przydatne, gdy stałe mają być używane w tym samym pliku na górze strony i do celów intellisense; jednak, jeśli mają być przeniesione do niezależnej klasy, użycie wielkich liter nie zrobiłoby dużej różnicy, jako przykład:

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

Nadal używam wielkich liter dla wartości const, ale jest to bardziej z przyzwyczajenia niż z jakiegokolwiek konkretnego powodu.

Oczywiście sprawia, że łatwo od razu zobaczyć, że coś jest const. Pytanie do mnie brzmi: czy naprawdę potrzebujemy tych informacji? Czy pomaga nam to w jakiś sposób uniknąć błędów? Jeśli przypisam wartość do const, kompilator powie mi, że zrobiłem coś głupiego.

Mój wniosek: idź z łuską wielbłąda. Może ja też zmienię swój styl ;-)

Edit:

To, że coś pachnie węgierskim nie jest tak naprawdę słusznym argumentem, IMO. Pytanie zawsze powinno brzmieć: Czy to pomaga, Czy boli?

Są przypadki, kiedy Węgierski pomaga. Obecnie nie jest ich tak wiele, ale nadal istnieją.

Po pierwsze, notacja węgierska jest praktyką używania prefiksu do wyświetlania typu danych parametru lub zamierzonego zastosowania. Konwencje nazewnicze Microsoftu mówi " nie " Węgierskiej notacji http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

Używanie wielkich liter nie jest zalecane, jak podano tutaj: Przypadek Pascala to akceptowalna konwencja i krzykliwe czapki. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft stwierdza również tutaj, że wielkie litery mogą być używane, jeśli jest to zrobione, aby dopasować istniejący schemat. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

To wszystko podsumowuje.

Zostaw Węgrów Węgrom.

W przykładzie pominąłbym nawet ostateczny artykuł i po prostu poszedł z

private const int Answer = 42;

To jest odpowiedź czy to jest odpowiedź?

*wykonane edit jako Pascal ściśle poprawne, jednak myślałem, że pytanie szukało bardziej odpowiedzi na życie, wszechświat i wszystko .

W artykule Constants (C# Programming Guide) Microsoft podaje następujący przykład:

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

Zatem dla stałych wydaje się, że Microsoft zaleca użycie camelCasing. Ale zauważ, że te stałe są zdefiniowane lokalnie .

Prawdopodobnie nazewnictwo widocznych na zewnątrz stałych jest bardziej interesujące. W praktyce Microsoft dokumentuje swoje stałe publiczne w bibliotece klas. NET jako pola . Oto kilka przykładów:

• Int32.MaxValue
• String.Pusty (właściwie, static readonly)
• Matematyka.PI
• Matematyka.E

Pierwsze dwa są przykładami PascalCasing. Trzeci wydaje się być zgodny z konwencjami Microsoftu z kapitalizacją dla dwuliterowego akronimu (chociaż pi nie jest akronimem). A czwarty wydaje się sugerować, że zasada dla dwuliterowy akronim rozszerza się na pojedynczy akronim lub identyfikator, taki jak E (który reprezentuje stałą matematyczną e).

Ponadto, w dokumencie Konwencji kapitalizacji, Microsoft Bardzo bezpośrednio stwierdza, że identyfikatory pól powinny być nazwane za pomocą PascalCasingi podaje następujące przykłady dla MessageQueue.InfiniteTimeout i UInt32.Min :

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

Wniosek: Użyj PascalCasing dla stałych publicznych (które są udokumentowane jako pola const lub static readonly).

Wreszcie, o ile wiem, Microsoft nie opowiada się za konkretnymi konwencjami nazewnictwa lub kapitalizacji dla prywatnych identyfikatorów, Jak pokazano w przykładach przedstawionych w pytaniu.

Właściwie wolę PascalCase tutaj-ale z przyzwyczajenia, jestem winny UPPER_CASE...

ALL_CAPS jest pobrany z C i C++ sposób pracy wierzę. Ten artykuł tutaj wyjaśnia, jak powstały różnice w stylu.

W nowych IDE, takich jak Visual Studio, łatwo jest zidentyfikować typy, zakres i jeśli są one stałe, więc nie jest to bezwzględnie konieczne.

Oprogramowanie FxCop i Microsoft StyleCop pomoże Ci podać wytyczne i sprawdzić kod, aby każdy działał tak samo.