Konwencja nazewnictwa C # dla stałych?

private const int THE_ANSWER = 42;

lub

private const int theAnswer = 42;

Osobiście uważam, że z nowoczesnymi IDE powinniśmy wybrać camelCase, ponieważ ALL_CAPS wygląda dziwnie. Co myślisz?

Zaleca się stosowanie konwencji nazewnictwa i wielkich liter P ascal C asing dla stałych (Microsoft ma narzędzie o nazwie StyleCop, które dokumentuje wszystkie preferowane konwencje i może sprawdzić źródło pod kątem zgodności - choć jest to zbyt anonimowe zachowanie dla gustów wielu osób) . na przykład

private const int TheAnswer = 42;

Konwencja pisowni wielkimi literami Pascala jest również udokumentowana w Wytycznych projektowych Microsoft Framework .

Wizualnie, wielka litera to droga. W ten sposób jest to tak rozpoznawalne. Ze względu na wyjątkowość i brak szansy na zgadywanie głosuję na UPPER_CASE!

const int THE_ANSWER = 42;

Uwaga : Wielkie litery będą przydatne, gdy stałe będą używane w tym samym pliku na górze strony i do celów inteligencji; gdyby jednak zostały przeniesione do niezależnej klasy, użycie wielkich liter nie zrobiłoby dużej różnicy, na 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 lose its charm
private void DoSomething(){
var getCons1 = Constant.Cons1;
var getCons2 = Constant.coNs2;
var getCons3 = Constant.cOns3;
var getCons4 = Constant.CONS4;
 }

Właściwie to jest

private const int TheAnswer = 42;

Przynajmniej jeśli spojrzysz na bibliotekę .NET, której IMO jest najlepszym sposobem na określenie konwencji nazewnictwa - aby twój kod nie wyglądał nie na miejscu.

Nadal używam wielkich liter dla stałych, ale jest to bardziej z przyzwyczajenia niż z jakiegokolwiek konkretnego powodu.

Oczywiście ułatwia natychmiastowe stwierdzenie, że coś jest stałe. Pytanie do mnie brzmi: czy naprawdę potrzebujemy tych informacji? Czy pomaga nam to w jakikolwiek sposób uniknąć błędów? Jeśli przypiszę wartość do const, kompilator powie mi, że zrobiłem coś głupiego.

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

Edytować:

To, że coś pachnie po węgiersku, nie jest tak naprawdę uzasadnionym argumentem, IMO. Pytanie powinno zawsze brzmieć: czy to pomaga, czy boli?

Zdarzają się przypadki, gdy węgierski pomaga. Nie tak wielu w dzisiejszych czasach, ale nadal istnieją.

Po pierwsze, notacja węgierska polega na stosowaniu przedrostka do wyświetlania typu danych parametru lub zamierzonego zastosowania. Konwencje nazewnictwa firmy Microsoft dotyczące odmowy notacji węgierskiej http://en.wikipedia.org/wiki/Hungarian_notation http://msdn.microsoft.com/en-us/library/ms229045.aspx

Używanie wielkich liter nie jest zalecane, jak stwierdzono tutaj: Pascal Case jest akceptowalną konwencją i KRZYWKAMI. http://en.wikibooks.org/wiki/C_Sharp_Programming/Naming

Microsoft stwierdza również, że można użyć DUŻYCH LAS, jeśli jest to zrobione w celu dopasowania do istniejącego schematu. http://msdn.microsoft.com/en-us/library/x2dbyw72.aspx

To właściwie podsumowuje.

W artykule Stałe (Podręcznik programowania w języku C #) 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;
}

W przypadku stałych wydaje się, że Microsoft zaleca użycie camelCasing. Pamiętaj jednak, że te stałe są zdefiniowane lokalnie .

Prawdopodobnie nazwanie widocznych z 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.Empty (faktycznie, static readonly)
• Math.PI
• Math.E

Pierwsze dwa są przykładami PascalCasing. Trzeci wydaje się być zgodny z konwencjami wielkich liter Microsoftu dla dwuliterowego akronimu (chociaż pi nie jest akryonimem). A czwarty wydaje się sugerować, że reguła dla dwuliterowego akryonimu rozciąga się na jednoliterowy akronim lub identyfikator taki jak E(który reprezentuje stałą matematyczną e ).

Ponadto w dokumencie Konwencje kapitalizacji, Microsoft bardzo bezpośrednio stwierdza, że identyfikatory pola powinno być nazwane przez PascalCasingi podaje następujące przykłady MessageQueue.InfiniteTimeout i UInt32.Min :

public class MessageQueue
{
    public static readonly TimeSpan InfiniteTimeout;
}

public struct UInt32
{
    public const Min = 0;
}

Wniosek: Użyj PascalCasingdla stałych publicznych (które są udokumentowane jako constlub static readonlypola).

Wreszcie, o ile mi wiadomo, Microsoft nie zaleca określonych konwencji nazewnictwa lub wielkich liter dla prywatnych identyfikatorów, jak pokazano w przykładach przedstawionych w pytaniu.

Pozostaw Węgier Węgierom.

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

private const int Answer = 42;

Czy to odpowiedź, czy to odpowiedź?

* Dokonałem edycji jako Pascal ściśle poprawnej, ale myślałem, że pytanie szukało więcej odpowiedzi na życie, wszechświat i wszystko .

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

Uważam, że ALL_CAPS pochodzi ze sposobu pracy w C i C ++. Ten artykuł tutaj wyjaśnia, w jaki sposób różnice w stylu doszło.

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

Oprogramowanie FxCop i Microsoft StyleCop pomoże ci podać wytyczne i sprawdzić kod, aby wszyscy działali w ten sam sposób.