Konwencja nazewnictwa zmiennych w języku programowania C # [zamknięte]

Oglądam film na C # o zmiennych. Autor deklaruje zmienną w metodzie i nazwał ją tak: string MyName = "James";

moje pytanie brzmi: która konwencja jest zalecana przez .Net Framework. Czy jest to obudowa Pascala jak w powyższym przykładzie, czy jest to obudowa wielbłąda?

c# coding-standards variables conventions

— Kaser
źródło

Problem z tym pytaniem, o którym nie wiedziałeś, więc to nie twoja wina, polega na tym, że w rzeczywistości nie ma konwencji kanonicznej dla C #. Istnieją wspólne konwencje; niestety więcej niż jeden, ale uzyskanie odpowiedzi tutaj byłoby czystą opinią. Przepraszam, głosowanie za zamknięciem; moja sugestia: Poświęć trochę czasu na czytanie kodu w popularnych repozytoriach github i codeplex, aby zobaczyć, jakich konwencji używają, ponieważ ludzie, którzy piszą większość popularnych, są doświadczonymi w branży ludźmi i kanoniczni wobec tego, co jest powszechne.

— Jimmy Hoffa

Konwencje nazewnictwa z MSDN - msdn.microsoft.com/en-us/library/xzf533w0(v=vs.71).aspx

— Yusubov

@Yusubov Opisują nazywanie części publicznych bibliotek, a nie zmiennych lokalnych.

— sick

Odpowiedzi:

Nie sądzę, że istnieje coś takiego jak „oficjalna” konwencja. O ile mi wiadomo, wielu doświadczonych programistów C # uważa za dobrą praktykę:

PascalCase for public member variables (string MyName = "James")

camelCase for local variables (string myName = "James")

_leadingUnderscore for private member variables (string _myName = "James")

Dzięki takiemu podejściu można rozróżnić zmienne lokalne, a także członków publicznych i prywatnych na podstawie pierwszej litery.

Podobnie jak w przypadku każdej konwencji kodowania, podlega to również osobistym preferencjom. Dlatego nie ma jednoznacznej odpowiedzi. Ogólnym celem powinno być utrzymanie kodu tak, aby był jak najbardziej czytelny i zrozumiały.

— spojrzał
źródło

+1 Jest to zbliżone do stylu, który widziałem. Uważam, że jest to ogólnie wzięte ze stylu użytego w przykładach MSDN. Zwykle widzę, jak dostają nieruchomości PascalCase, lokalni camelCasei prywatni członkowie _leadingUnderscore.

— KChaloux

Czy masz na myśli pola lub właściwości, kiedy mówiłeś o zmiennych członkowskich?

— Kaser

Delphi deweloperzy mają tendencję do parametrów nazwisko funkcja / metoda poprzedzając je z „A” (aParameter: string). Zdaję sobie sprawę, że parametry są zasadniczo zmiennymi lokalnymi, szczególnie gdy są przekazywane przez wartość, ale często bardzo pomocne jest „zobaczenie”, że var jest przekazywany jako parametr. Czy istnieje taka konwencja w C #?

— Marjan Venema

I jeszcze jeden: pola członków. Delfy poprzedzają je literą „F”. Widziałem kodu C #, który deklaruje je znakiem podkreślenia: private string _SomeString. Czy powiedziałbyś, że to konwencja? (Po prostu zanurzam palce w C # i zastanawiam się nad tym).

— Marjan Venema

To jest niedokładne. Istnieją opublikowane konwencje nazewnictwa dla członków publicznych (i klas publicznych itp.).

— sick

Konwencje nazewnictwa .Net Framework ( v4.5 , v1.1 ) są agnostyczne. Nie określają standardu nazewnictwa zmiennych lokalnych. Musisz nazwać własną konwencję.

Ja osobiście używam camelCase i w razie potrzeby rozróżniam zmienne składowe od nazw parametrów this. Ale wiodące podkreślenia (tj. _memberVariable) Są również ważne.

— Robert Harvey
źródło

To jest właśnie powód stosowania konwencji nazewnictwa - wykorzystywania thisdo odróżniania zmiennych lokalnych od pól / właściwości. 5 dodatkowych liter za każdym razem to za dużo imho.

— Sinatr