Podkreślanie lub nie podkreślanie - oto jest pytanie

Czy są jakieś problemy z nieprzedrostowaniem pól prywatnych z podkreśleniem w C #, jeśli wersja binarna ma być używana przez inne języki ramowe? Na przykład, ponieważ C # rozróżnia wielkość liter, możesz wywołać pole „foo” i właściwość publiczną „Foo” i działa dobrze.

Czy miałoby to jakikolwiek wpływ na język bez rozróżniania wielkości liter, taki jak VB.NET, czy wystąpią jakiekolwiek problemy ze zgodnością ze specyfikacją CLS (lub innymi), jeśli nazwy można rozróżnić tylko po wielkości liter?

Nie przyniesie to żadnego efektu.

Część zaleceń do pisania bibliotek zgodnych z systemem CLS jest nie mieć dwa publicznych / chronione podmioty, które różnią się tylko wielkością liter, np powinieneś nie mieć

public void foo() {...}

i

public void Foo() {...}

to, co opisujesz, nie stanowi problemu, ponieważ element prywatny nie jest dostępny dla użytkownika biblioteki

WAŻNA AKTUALIZACJA (12 kwietnia 2016):

Zwrócono nam uwagę, że wewnętrzny standard zespołu .NET CoreFX kładzie nacisk na używanie notacji podkreślenia bez podania przyczyny. Jednak jeśli przyjrzymy się bliżej Zasada # 3 staje się oczywiste, że nie jest to system _, t_, s_przedrostków, które sugeruje, dlaczego _został wybrany w pierwszej kolejności.

3. Używamy _camelCasedo pól wewnętrznych i prywatnych i używamy tylko do odczytu, jeśli to możliwe. Przedrostki pól instancji za pomocą _, pola statyczne z polami statycznymi s_i łącz je za pomocą t_. Przy stosowaniu na polach statycznych, readonlypowinny pochodzić po static(czyli static readonlyniereadonly static ).
4. Unikamy, this.chyba że jest to absolutnie konieczne.

Więc jeśli jesteś jak zespół .NET CoreFX pracujący nad jakimś krytycznym dla wydajności, wielowątkowym kodem na poziomie systemu , to MOCNIE SUGEROWANE jest, że:

• przestrzegać ich standardów kodowania i
• użyj notacji podkreślenia i
• nie czytaj dalej tej odpowiedzi

W przeciwnym razie czytaj dalej ...

ORYGINALNA ODPOWIEDŹ:

Najpierw ustalmy, o czym mówimy. Pytanie brzmi, w jaki sposób uzyskujemy dostęp do elementów członkowskich instancji z metod niestatycznych i konstruktorów klasy / podklas, jeśli pozwalają na to modyfikatory widoczności.

Notacja z podkreśleniem

• sugeruje użycie przedrostka „_” w nazwach pól prywatnych
• mówi też, że nigdy nie powinieneś używać „tego”, chyba że jest to absolutnie konieczne

Ten zapis

• sugeruje, aby zawsze używać „tego”. aby uzyskać dostęp do dowolnego członka instancji

Dlaczego istnieje ta notacja?

Ponieważ tak właśnie jest

• odróżniają parametr od pola, gdy mają tę samą nazwę
• upewnij się, że pracujesz w kontekście bieżącej instancji

Przykład

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Dlaczego istnieje notacja podkreślenia?

Niektórzy ludzie nie lubią wpisywać „to”, ale nadal potrzebują sposobu na odróżnienie pola od parametru, więc zgodzili się użyć znaku „_” przed polem

Przykład

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

Można by pomyśleć, że to kwestia osobistego gustu, a oba sposoby są równie dobre / złe. Istnieją jednak pewne aspekty, w których ten zapis jest lepszy od znaku podkreślenia:

Przejrzystość

• znaki podkreślenia zaśmiecają nazwy
• ten zapis utrzymuje nazwy w stanie nienaruszonym

Ładunek kognitywny

• podkreślenie-notacja jest niespójna, sprawia, że ​​traktujesz pola w specjalny sposób, ale nie możesz go używać z innymi członkami, za każdym razem, gdy musisz zadać sobie pytanie, czy potrzebujesz właściwości lub pola

• ten zapis jest spójny, nie musisz myśleć, po prostu zawsze używasz „tego” w odniesieniu do dowolnego członka

AKTUALIZACJA: jak wskazano, poniższe nie są zaletą

Konserwacja

• podkreślenie-notacja wymaga _zwrócenia uwagi podczas refaktoryzacji, powiedzmy, że zmienisz pole we właściwości (usuń _) lub odwrotnie (dodaj _)

• ta notacja nie ma takiego problemu

Autouzupełnianie

Kiedy chcesz zobaczyć listę członków instancji:

• notacja podkreślenia nie pomaga zbytnio, ponieważ po wpisaniu „_” wyskakujące okienko autouzupełniania pokazuje pola prywatne i wszystkie typy dostępne w połączonych zestawach zmieszane z pozostałymi członkami instancji
• ta notacja daje jasną odpowiedź, wpisując „to” widzisz tylko listę członków i nic więcej

Dwuznaczność

Czasami masz do czynienia z kodem bez pomocy Intellisense. Na przykład, gdy przeglądasz kod lub przeglądasz kod źródłowy online.

• podkreślenie-notacja jest niejednoznaczne: kiedy widzisz Something.SomethingElse, nie możesz stwierdzić, czy Something jest klasą, a SomethingElse jest jego statyczną właściwością ... lub może Something jest bieżącą właściwością instancji, która ma własną właściwość SomethingElse

• ta notacja jest jasna: Kiedy widzisz Something.SomethingElse, może to oznaczać tylko klasę z właściwością statyczną, a kiedy widzisz this.Something.SomethingElse, wiesz, że Something jest składnikiem, a SomethingElse jest jego własnością

Metody rozszerzające

Nie możesz używać metod rozszerzeń w samej instancji bez użycia „this”.

• podkreślenie-notacja wymaga, abyś nie używał "this", jednak z metodami rozszerzającymi musisz
• ta notacja chroni cię przed wahaniem, zawsze używasz „tego”, kropka.

Obsługa programu Visual Studio

• podkreślenie notacji nie ma wbudowanej obsługi w programie Visual Studio

• ta notacja jest oczywiście obsługiwana przez Visual Studio:

  1. "To." Kwalifikacja : preferuj, aby wszystkie pola niestatyczne używane w metodach niestatycznych były poprzedzone this.w języku C #

Oficjalne rekomendacje

Istnieje wiele oficjalnych wskazówek, które wyraźnie mówią „nie używaj podkreśleń”, zwłaszcza w języku C #

• podkreślenie-notacja pochodzi z C ++, gdzie jest to ogólna praktyka, która pomaga uniknąć konfliktów nazw, jest również zalecana dla VisualBasic.Net w celu rozwiązania problemu, w którym pole „wartość” i właściwość „Wartość” mają w rzeczywistości tę samą nazwę, ponieważ VisualBasic nie rozróżnia wielkości liter

  1. Zadeklarowane nazwy elementów w Visual Basic
  2. Pola zapasowe w VisualBasic.NET

• ta notacja jest zalecana dla C #, podczas gdy „_” jest jawnie zabronione:

  1. to słowo kluczowe w C #
  2. Wskazówki dotyczące użycia pól : nie stosuj przedrostka do nazw pól ani do nazw pól statycznych.
  3. Wytyczne dotyczące nazw: Nazwy członków typu : nie używaj przedrostka dla nazw pól.
  4. Ogólna konwencja dotycząca nazewnictwa : X NIE WOLNO używać znaków podkreślenia, łączników ani żadnych innych znaków niealfanumerycznych
  5. Reguła dotycząca zapewniania jakości CA1707 : Identyfikatory nie powinny zawierać podkreślenia
  6. Używanie podkreślenia nie jest zgodne z CLS (dla identyfikatorów publicznych i chronionych)
  7. Konwencja nazewnictwa wewnętrznego programistów .NET Framework : nie używaj przedrostka dla zmiennych składowych. Jeśli chcesz rozróżnić zmienne lokalne i składowe, powinieneś użyć „this”. w języku C # i „Ja”. w VB.NET.

Zaczerpnięte z pliku pomocy Microsoft StyleCop:

TypeName: FieldNamesMustNotBeginWithUnderscore

Identyfikator kontrolny: SA1309

Przyczyna: nazwa pola w C # zaczyna się od podkreślenia.

Opis reguły:

Naruszenie tej reguły ma miejsce, gdy nazwa pola zaczyna się od podkreślenia.

Domyślnie StyleCop nie zezwala na używanie podkreśleń, m_ itp. Do oznaczania pól klas lokalnych, na rzecz opcji „this”. prefiks. Zaleta używania „this”. polega na tym, że dotyczy to w równym stopniu wszystkich typów elementów, w tym metod, właściwości itp., a nie tylko pól, dzięki czemu wszystkie wywołania członków klas są natychmiast rozpoznawalne, niezależnie od tego, który edytor jest używany do przeglądania kodu. Kolejną zaletą jest to, że tworzy szybkie, rozpoznawalne rozróżnienie między składowymi instancji a elementami statycznymi, które nie będą poprzedzone prefiksem.

Jeśli nazwa pola lub zmiennej ma odpowiadać nazwie elementu skojarzonego z Win32 lub COM i dlatego musi zaczynać się od podkreślenia, umieść pole lub zmienną w specjalnej klasie NativeMethods. Klasa NativeMethods to dowolna klasa, która zawiera nazwę kończącą się na NativeMethods i jest przeznaczona jako symbol zastępczy dla opakowań Win32 lub COM. StyleCop zignoruje to naruszenie, jeśli element zostanie umieszczony w klasie NativeMethods.

Inny opis reguły wskazuje, że preferowaną praktyką oprócz powyższego jest rozpoczynanie pól prywatnych małymi literami, a publicznych dużymi.

Edycja: W ramach kontynuacji strona projektu StyleCop znajduje się tutaj: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . Przeczytanie pliku pomocy daje wiele informacji na temat tego, dlaczego sugerują różne zasady stylistyczne.

Ponieważ mówimy o polu prywatnym, nie ma to wpływu na użytkownika Twojej klasy.

Ale polecam użycie podkreślenia w polu prywatnym, ponieważ może to ułatwić zrozumienie kodu, np .:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

W naszym zespole zawsze używamy przedrostka podkreślenia dla pól prywatnych. Dlatego czytając kod, mogę bardzo łatwo zidentyfikować pola prywatne i odróżnić je od lokalnych i argumentów. W pewnym sensie podkreślenie może być postrzegane jako skrócona wersja „tego”.

Po pracy w środowisku, które od tego czasu rządziło się bardzo specyficznymi i bezsensownymi zasadami stylu, zacząłem tworzyć własny styl. To jest jeden typ, który przerzucałem w tę iz powrotem na wiele. Ostatecznie zdecydowałem, że prywatne pola zawsze będą _field, zmienne lokalne nigdy nie będą miały _ i będą pisane małymi literami, nazwy zmiennych dla kontrolek będą luźno zgodne z notacją węgierską, a parametrami będą ogólnie camelCase.

this.Moim zdaniem nienawidzę słowa kluczowego, które po prostu dodaje zbyt dużo szumu w kodzie. Uwielbiam Resharper's usuń to zbędne. słowo kluczowe.

Aktualizacja 6-letnia: analizowałem wewnętrzne elementy pod Dictionary<TKey,T>kątem określonego wykorzystania równoczesnego dostępu i błędnie odczytałem pole prywatne jako zmienną lokalną. Pola prywatne z pewnością nie powinny mieć tej samej konwencji nazewnictwa, co zmienne lokalne. Gdyby było podkreślenie, byłoby to niezwykle oczywiste.

Podoba mi się podkreślenie, ponieważ wtedy mogę użyć nazwy małej litery jako parametrów metody w następujący sposób:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

Nadal bardzo lubię używać podkreśleń przed polami prywatnymi z powodu, o którym wspomniał Martin, a także dlatego, że pola prywatne będą następnie sortowane razem w IntelliSense. Dzieje się tak pomimo zła węgierskich notacji przedrostków w ogóle.

Jednak ostatnio stwierdzam, że używanie przedrostka podkreślenia w przypadku prywatnych członków jest źle widziane, chociaż nie jestem do końca pewien, dlaczego. Może ktoś inny wie? Czy to tylko zasada przedrostka? A może było coś związanego z zniekształcaniem nazw typów ogólnych, które uzyskują w nich podkreślenia w skompilowanych zespołach, czy coś?

Jeśli chcesz, abyś zagłębił się w .NET Framework w stylu rekomendacji gliniarza, pokazuje, że zmienne składowe są często używane przez „_”. Cokolwiek zalecają twórcy Style Cop, to nie jest to, czego używa większość pracowników MS. :) Więc będę się trzymał podkreślenia. Ponieważ osobiście popełniam znacznie mniej błędów, używając podkreślenia niż this (przykład: używając varName = varName zamiast this.varName = varName, naprawdę tkwi we mnie)

Myślę, że ogólnie rzecz biorąc pola na poziomie klasowym są błędem w projektowaniu języka. Wolałbym, żeby właściwości C # miały swój własny zakres lokalny:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Umożliwiłoby to całkowite zaprzestanie używania pól.

Jedyny przypadek, w którym poprzedzam pole prywatne znakiem podkreślenia, ma miejsce, gdy właściwość wymaga oddzielnego pola zapasowego. To też jedyny raz, kiedy korzystam z pól prywatnych. (A ponieważ nigdy nie używam pól chronionych, wewnętrznych ani publicznych, to jedyny przypadek, w którym używam okresu pól.) Jeśli o mnie chodzi, jeśli zmienna musi mieć zasięg klasy, jest to własność klasy.

Zapis _fieldName dla pól prywatnych jest tak łatwy do złamania . Używając „tego”. notacji nie da się złamać. Jak przerwałbyś _ notację? Przestrzegać:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

Proszę bardzo, właśnie naruszyłem twoją konwencję nazewnictwa, ale się kompiluje. Wolałbym mieć konwencję nazewnictwa, która a) nie jest węgierska ib) wyraźna. Jestem zwolennikiem zniesienia węgierskiego nazewnictwa i to w pewnym sensie się kwalifikuje. Zamiast typu obiektu przed nazwą zmiennej masz jej poziom dostępu.

Porównaj to z Rubim, gdzie nazwa zmiennej @my_number wiąże nazwę z zakresem i jest nierozerwalna.

edycja: ta odpowiedź stała się negatywna. Nie obchodzi mnie to, zostaje.

Jeśli chcesz, aby zestaw był zgodny z CLS, możesz użyć atrybutu CLSCompliant w pliku informacji o zespole. Kompilator będzie wtedy narzekał, gdy Twój kod zawiera elementy niezgodne z CLS.

Następnie, gdy masz 2 właściwości, które różnią się tylko wielkością liter, kompilator wyświetli błąd. Z drugiej strony, jeśli masz pole prywatne i własność publiczną w tej samej klasie, nie będzie problemów.

(Ale zawsze zawsze poprzedzam moich prywatnych członków podkreśleniem. Pomaga mi to również w zrozumieniu, kiedy czytam kod, że dana zmienna jest polem członkowskim).

Lubię używać podkreśleń przed moimi prywatnymi polami z dwóch powodów. Wspomniano już o tym, że pola wyróżniają się na podstawie powiązanych z nimi właściwości w kodzie i Intellisense. Drugim powodem jest to, że mogę używać tych samych konwencji nazewnictwa, niezależnie od tego, czy koduję w VB, czy C #.

Nie ma żadnych implikacji. Podczas kompilacji kodu wszystko, co jest ważne dla kompilatora, to przestrzeń nazw i widoczność pola / właściwości. Podkreślenie jest tak samo ważne, jak każdy inny znak podczas nadawania nazwy identyfikatorowi. Prawdziwą sztuczką jest użycie konwencji, którą zrozumiesz ty i ludzie wokół ciebie.