2011-12-13 12 views
31

Jest kilka pytań na ten temat, ale wszystkie zdawały się być ukierunkowane na określoną część języka;Jakie są konwencje nazewnictwa w języku C#?

jestem dopiero zaczyna się w C# z przyjacielem w przedsięwzięciu do tworzenia gier na Xbox Live Arcade. Opracowałem wiele gier za pomocą ActionScript 2 i 3, ale chcę zacząć odkrywać bardziej zaawansowane języki i urządzenia.

Chcę się upewnić, że nie obrażam ludzi, z którymi zaczynam pracować (jeśli do tego dojdę) lub nawet ludzi tutaj, gdy wpadam w kłopoty i zadaję pytanie z poważnym niepokojącym/"niepoprawnym" nazewnictwem metod, itp.

Znalazłem to mylące w przykładowym kodzie, który widziałem, ponieważ wydaje się, że z mojego obecnego punktu widzenia niektóre wady. Wątpię, żeby wykorzystano wadliwą konwencję nazewnictwa, więc zdaję sobie sprawę, że mam problem ze zrozumieniem.

O ile mogę powiedzieć tak daleko, tam są te konwencje:

  • public Type SomeMethod()
  • private Type SomeMethod() - bez podkreślenia lub cokolwiek?
  • public static Type SomeMethod()
  • private static Type _SomeMethod() - ten właśnie wydaje się dziwne ..
  • public Type someProperty - włączenie go do wielbłąda obudowy dla właściwości?
  • public static Type SomeProperty - a następnie wracając do pascal obudowy dla statycznych ..

W języku ActionScript 3, Mam opracowane i ściśle trzymać się tych konwencji:

  • private var _someVar
  • public var someVar
  • private function _someMethod()
  • public function someMethod()
  • public static var SomeStaticVar
  • public static function SomeStaticMethod()
  • public const SOME_CONSTANT

Czy istnieje pełna lista konwencji nazewnictwa z rozumowania za siebie tak, że mogę dostać głowę wokół nich? Odwrócenie składni (np. public Type method() zamiast AS2-a public function method():Type) wyrzuca mnie wystarczająco, w momencie, gdy wiem, że muszę mieć oko na to, jak nazywam rzeczy, inaczej zapomnę i rozwiną złe nawyki, które " raczej gwoźdź i unikaj teraz.

+0

Nie sądzę, że istnieje jedna konwencja - mam tendencję do oglądania różnych stylów używanych przez różnych programistów. Najważniejszą rzeczą jest być konsekwentnym w całym kodzie, jak sądzę. Wybierz konwencję i trzymaj się jej. –

+0

Niektóre wytyczne Microsoftu: http://msdn.microsoft.com/en-us/library/ms229045.aspx i kilka poradników, które uważam za przydatne: http://csharpguidelines.codeplex.com – Otiel

Odpowiedz

19

Jest All-In-One Code Framework Coding Standards firmy Microsoft, który zawiera kompletny zestaw reguł i wytycznych. (Dostępny również here)

Ten dokument opisuje wytycznych styl kodowania dla macierzystym C++ i .NET (C# i VB.NET) programowania używany przez Microsoft All-In-One Code Framework zespołu projektowego.

+21

Link do linku Non-Scribd: http://1code.codeplex.com/downloads/get/357518?releaseId=84683 – larspars

+0

Zapłać za skrybd – rolls

+1

@rolls Możesz przeglądać dokument na scribd ** lub ** codeplex za darmo . Jeśli chcesz go pobrać, użyj linku codeplex. – Nasreddine

7

Istnieje wiele konwencji nazewniczych zalecanych przez Microsoft do programowania .Net. Możesz przeczytać o tych here.

Zgodnie z ogólną zasadą, użyj PascalCase dla właściwości publicznej, metody i nazwy typu.

Dla parametrów i zmiennych lokalnych użyj polecenia camelCase.

Dla pól prywatnych, wybierz jedną: niektóre korzystają z camelCase, innego prefiksu _camelCase z _.

Powszechnie spotykaną konwencją jest również nazywanie stałych za pomocą ALLCAPS.

+1

Chyba konwencja all-caps jest reliktem starych stylów kodowania pochodzących z C. To jest zdecydowanie coś, czego nie znajdziesz wśród standardowych stałych .NET lub wyliczeń. – Palec

+0

Używam ALLCAPS do wyliczenia i stałych w C# nadal jak większość czasu używam ich z DLLami C++ interd – rolls

47

Dwie główne kapitalizacje to camelCase i PascalCase.

Podstawowe zasady (z dużą ilością odmian) są

  • Rodzaje używać PascalCase
  • właściwości i metody zawsze używać PascalCase
  • członkowie publicznych (pola, consts) używają PascalCase
  • zmienne lokalne używać Parametry camelCase
  • Parametry używają camelCase

I choć the documentation państw, które „pola wewnętrzne i prywatne nie są objęte wytycznymi” istnieją pewne wyraźne konwencje:

  • pola prywatnego użytku CamelCase
  • prywatne pola, które kopii prefiks majątkowego _
+1

@ Henk. Wat o chronionych i statycznych polach? –

+4

_ jest zabronione w konwencji 'Microsoft'' nazewnictwa. – Yoda

+0

@Yoda - jaka wersja/rok? Stwardnienie rozsiane było nieugięte w tej sprawie, kiedy pojawił się Fx 1, ale kilka lat później powszechnie używane były pola prefiksowe. –

3

C# preferuje PascalCasing dla klas, właściwości i metod.

O ile mogę powiedzieć tak daleko, tam są te konwencje:

  • public Type SomeMethod() < - tak
  • private Type SomeMethod() < - poprawna, bez podkreślenia
  • public static Type SomeMethod() < - poprawna
  • private static Type _SomeMethod() < - Wydaje mi się to dziwne. podkreślenia nie powinno tam być
  • public Type someProperty < - nie, własność publiczna powinna być PascalCased (SomeProperty)
  • public static Type SomeProperty - a następnie wracając do pascal obudowy dla statycznych ..

Jeśli używasz wizualna Studio lub XNA Game Studio (co moim zdaniem jest widelcem Visual Studio), gorąco polecam wyskoczenie na licencję ReSharper (z oprogramowania jetbrains). W swoim edytorze kodu powiedzą ci, jak dostosować się do zwykłych konwencji C#.

Dodatek:

Należy użyć camelCasing dla prywatnych pól i argumentów metod. W przypadku pól prywatnych zwykle poprzedzam je _withAnUnderscore.

Powiązane problemy