Konwencja nazewnicza-podkreślenie w zmiennych C ++ i C #

Podkreślanie to tylko konwencja, nic więcej. Dlatego jego użycie jest zawsze nieco inne dla każdej osoby. Oto jak je rozumiem w tych dwóch językach:
W C ++ znak podkreślenia zwykle wskazuje prywatną zmienną składową.
W C # zwykle widzę, że jest używany tylko podczas definiowania podstawowej zmiennej składowej prywatnej dla właściwości publicznej. Inne zmienne składowe prywatne nie będą miały podkreślenia. Jednak wraz z pojawieniem się automatycznych właściwości, to zastosowanie w dużej mierze zniknęło w tle.
Przed:

private string _name;

public string Name

{

 get { return this._name; }

 set { this._name = value; }

}

Po:

public string Name { get; set; }

Najlepszym rozwiązaniem jest NIEUŻYWANIE PODNOŚNIKÓW przed nazwą zmiennej lub nazwą parametru w C ++

Nazwy zaczynające się od podkreślenia lub podwójnego podkreślenia są ZAREZERWOWANE dla programistów C ++. Podkreślone nazwy są zarezerwowane do obsługi biblioteki.
Jeśli przeczytasz standard kodowania C ++, zobaczysz, że na pierwszej stronie jest napisane:

„Nie przeciążaj konwencji nazewnictwa, ale używaj spójnej konwencji nazewnictwa: wymagane są tylko dwie opcje: a) nigdy nie używaj„ podstępnych nazw ”, które zaczynają się od podkreślenia lub zawierają podwójne podkreślenie;” (p2, Standardy kodowania C ++, Herb Sutter i Andrei Alexandrescu)

Bardziej szczegółowo,

w wersji roboczej
http://www.open-std.org/jtc1/s ... 6.pdf
ISO określa aktualne zasady:

Ponadto niektóre identyfikatory są zarezerwowane do użytku przez implementacje C ++ i nie powinny być używane w inny sposób; nie jest wymagana diagnostyka. (a) każdy identyfikator zawierający podwójny podkreślnik __ lub rozpoczynający się od podkreślenia, po którym następuje duża litera, jest zastrzeżony do implementacji w jakimkolwiek celu. (b) każdy identyfikator zaczynający się od podkreślenia jest implementacją zarezerwowaną do użytku jako nazwa w globalnej przestrzeni nazw.

Najlepiej nie zaczynać znaku od podkreślenia, jeśli przypadkowo napotkasz jedno z powyższych ograniczeń.
Możesz zobaczyć, dlaczego takie użycie podkreśleń może mieć katastrofalne skutki w tworzeniu oprogramowania:
Spróbuj skompilować prosty program helloWorld.cpp w następujący sposób:

g++ -E helloWorld.cpp

Zobaczysz wszystko, co dzieje się w tle. Oto fragment:

ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);

 try

 {

 __streambuf_type* __sb = this->rdbuf();

 if (__sb)

 {

 if (__sb->pubsync() == -1)

 __err |= ios_base::badbit;

 else

 __ret = 0;

 }

Możesz zobaczyć, ile nazw zaczyna się od podwójnego podkreślenia!
Ponadto, jeśli spojrzysz na wirtualne funkcje składowe, zobaczysz, że * _vptr jest wskaźnikiem generowanym do wirtualnej tabeli, która jest tworzona automatycznie, gdy używasz jednej lub więcej wirtualnych funkcji składowych w swojej klasie! Ale to już inna historia ...
Jeśli użyjesz podkreśleń, możesz napotkać problemy związane z konfliktem i nie będziesz wiedział, co je powoduje, dopóki nie będzie za późno.

Właściwie konwencja

_var

pochodzi z VB, a nie z C # czy C ++ (m _, ... to inna sprawa).
Doprowadziło to do przezwyciężenia niewrażliwości VB na wielkość liter podczas deklarowania właściwości.
Na przykład taki kod nie jest możliwy w VB, ponieważ traktuje

user

i

User

jako ten sam identyfikator

Private user As StringPublic Property User As String

 Get

 Return user

 End Get

 Set(ByVal Value As String)

 user = value

 End Set

End Property

Aby temu zaradzić, niektórzy zastosowali konwencję dodawania „_” do pola prywatnego, aby wyglądało to tak

Private _user As StringPublic Property User As String

 Get

 Return _user

 End Get

 Set(ByVal Value As String)

 _user = value

 End Set

End Property

Ponieważ wiele konwencji dotyczy .Net i aby zachować pewną spójność między konwencjami C # i VB.NET, używają tego samego.
Znalazłem link do tego, o czym mówiłem:

http://10rem.net/articles/net- ... tices
http://10rem.net/articles/net- ... Wielbłądowe etui z wiodącym podkreśleniem. W
VB.NET zawsze określa „Chroniony” lub
„Prywatne”, nie używaj „Przyciemnij”. Za pomocą
„m_” jest przestarzałe, podobnie jak użycie
nazwa zmiennej inna niż
właściwości tylko w przypadku, zwłaszcza z
chronione zmienne, ponieważ narusza
zgodność i uczyni twoje życie
bolesne, jeśli programujesz w VB.NET, ponieważ ty
muszą wymieniać swoich członków
coś innego niż właściwości
dostęp/mutator. Ze wszystkich
akapity tutaj, prowadząc podkreślenie
są rzeczywiście jedynymi kontrowersyjnymi.
Osobiście wolę to reżyserować
obudowa wielbłąda bez podkreślenia dla mojego
zmienne prywatne, więc tego nie robię
musisz kwalifikować nazwy zmiennych za pomocą „this”.
aby odróżnić je od parametrów w
konstruktorzy lub gdziekolwiek indziej, gdzie mam
prawdopodobnie dojdzie do kolizji nazw.
W przypadku VB.NET niewrażliwych na wielkość liter jest
nawet ważniejsze, ponieważ Twój
właściwości dostępu zwykle mają
to samo, co Twój prywatny członek
zmienne z wyjątkiem podkreślenia.
Jeśli chodzi o m_, tak naprawdę to tylko
o estetyce. Ja (i wielu innych)
znajdź m_ brzydki, jak to wygląda
że w nazwie zmiennej jest dziura. to
prawie obraźliwe. Użyłem go w
VB6 cały czas, ale tylko
ponieważ zmienne nie mogły mieć
początkowe podkreślenie. Nie mogłem
szczęśliwszy, że wychodzi. Microsoft
odradza używanie m_ (i
prosto _), chociaż zrobili i
oba w swoim kodzie. Przedrostek z
bezpośrednie „m” jest poprawne. Oczywiście,
ponieważ są one głównie kodowane w C #, mogą
mają tylko członków prywatnych, którzy się różnią
jeśli różnią się od właściwości. Ludzie
muszę zrobić coś innego. Zamiast
próbując wymyślić
język po języku w szczególnych przypadkach i
polecam początkowe podkreślenie dla
wszystkich języków, które będą go obsługiwać. Jeśli
chcę, aby moja klasa była kompletna
Zgodny z CLS, mogłem wyjść
prefiks dla każdego chronionego
Zmienne składowe C #. W praktyce jednak ja
nigdy się tym nie martw, bo wszystko zachowuję
potencjalnie chronione zmienne składowe
prywatne i zamiast tego chronione dostawy
akcesory i mutatory. Dlaczego?:
Krótko mówiąc, jest to umowa
prosty (jeden znak), łatwy do odczytania
(Twój wzrok nie jest rozpraszany przez innych
wiodące postacie) i pomyślnie
unika kolizji nazw z
zmienne na poziomie procedury i
właściwości na poziomie klasy.

Pierwszy komentator (R. Samuel Klatchko) odniósł się do:

jakie są zasady używania podkreślenia w identyfikatorze C ++?
https://coderoad.ru/228783/
który odpowiada na pytanie o podkreślenie w C ++. Generalnie nie powinieneś używać początkowego podkreślenia, ponieważ jest on zarezerwowany dla programisty kompilatora. Kod, który widzisz za pomocą

_var

, jest prawdopodobnie kodem starszego typu lub kodem napisanym przez kogoś, kto dorastał przy użyciu starego systemu nazewnictwa, który nie nachmurzył się, gdy chodziło o podkreślenia.
Jak podają inne odpowiedzi, był używany w C ++ do identyfikowania zmiennych składowych klasy. Jednak tak naprawdę nie ma to znaczenia dla dekoratorów lub składni. Dlatego jeśli chcesz go użyć, skompiluje się.
Zostawię dyskusję o C # innym.

_var nie ma znaczenia i służy jedynie do ułatwienia rozpoznania, że ​​zmienna jest prywatną zmienną składową.
W C ++ używanie konwencji _var jest złą formą, ponieważ istnieją reguły regulujące użycie znaku podkreślenia przed identyfikatorem. _var jest zarezerwowany jako identyfikator globalny, podczas gdy _Var (podkreślenie + duża litera) jest zawsze zarezerwowany. Dlatego w C ++ zobaczysz ludzi używających konwencji var_.

Możesz stworzyć własne wytyczne dotyczące kodowania. Po prostu napisz przejrzystą dokumentację dla polecenia rest.
Użycie _field pomaga Intelilsense filtrować wszystkie zmienne klas, po prostu wpisując _.
Zwykle podążam

Zalecenia Brada Adamsa
http://blogs.msdn.com/b/brada/ ... .aspx, ale odradza używanie podkreśleń.

Standard nazewnictwa firmy Microsoft dla języka C # mówi, że zmienne i parametry muszą używać małych liter wielbłąda

IE:

paramName

. Standard wymaga również, aby pola miały ten sam formularz, ale może to prowadzić do rozmytego kodu, dlatego wiele poleceń wymaga podkreślenia przedrostka, aby poprawić przejrzystość

IE:

_fieldName

.

C #, Microsoft

Framework Design Guidelines
https://rads.stackoverflow.com ... 46756
sugeruje, aby nie używać podkreślenia dla

otwarty

członków. Dla

prywatny

znaki podkreślenia są używane przez OK. Tak właściwie

Jeffrey Richter
http://www.wintellect.com/cs/b ... .aspx
(często cytowane w podręczniku) używa na przykład m_ i A „s_” dla prywatnych statycznych członków.
Osobiście używam znaku _ tylko w odniesieniu do moich osobistych członków. „m_” i „s_” ograniczają się do notacji węgierskiej, która nie tylko jest mile widziana w .NET, ale może być dość rozwlekła, a dla klas z wieloma członkami trudno jest szybko przejrzeć oczy w kolejności alfabetycznej (wyobraź sobie 10 zmiennych zaczynających się od m_ ).

Używam nazewnictwa _var dla zmiennych składowych moich klas. Są dwa główne powody, dla których to robię:
1) pomaga mi śledzić zmienne klasowe i funkcjonalne zmienne lokalne podczas późniejszego czytania kodu.
2) pomaga w Intellisense (lub innym systemie uzupełniania kodu), gdy szukam zmiennej klasy. Znajomość pierwszego znaku jest przydatna do filtrowania listy dostępnych zmiennych i metod.

Jeśli chodzi o języki C i C ++, podkreślenie w nazwie (początek, środek lub koniec) nie ma tak naprawdę znaczenia. To tylko poprawny znak nazwy zmiennej. „konwencje” wywodzą się z praktyki kodowania w społeczności programistów.
Jak wskazano w różnych przykładach powyżej, znak _ na początku może oznaczać prywatnych lub chronionych członków klasy w C ++.
Pozwólcie, że opowiem wam tylko krótką historię, która może być zabawną rzeczą. W systemie UNIX, jeśli masz główną funkcję biblioteki C i zaplecze jądra, w którym chcesz udostępnić funkcję jądra również przestrzeni użytkownika, _ utknie przed funkcją pośredniczącą, która bezpośrednio wywołuje funkcję jądra, nie robiąc nic innego. Najbardziej znanym i znanym przykładem tego jest exit () kontra _exit () w jądrach BSD i SysV: tam exit () działa w przestrzeni użytkownika przed wywołaniem usługi wyjścia jądra, podczas gdy _exit jest po prostu mapowane na usługę wyjścia jądra.
Więc _ było używane dla rzeczy "lokalnych", w tym przypadku lokalna była lokalna dla maszyny. Zwykle funkcja _functions () nie była przenośna. W takim przypadku nie należy oczekiwać takiego samego zachowania na różnych platformach.
Teraz co do _ w nazwach zmiennych, takich jak
int _foo;
Cóż, z psychologicznego punktu widzenia, wpisywanie _ jest dziwne na samym początku. Więc jeśli chcesz utworzyć nazwę zmiennej, która z mniejszym prawdopodobieństwem koliduje z czymś innym, ZWŁASZCZA podczas wymiany preprocesora, powinieneś rozważyć użycie _.
Moja główna rada brzmi: zawsze przestrzegaj konwencji swojej społeczności programistów, aby móc efektywniej współpracować.

Oznacza to po prostu, że jest to pole składowe klasy.

Nie ma określonej konwencji nazewnictwa, ale widziałem to dla prywatnych członków.

Z mojego doświadczenia (oczywiście ograniczone) podkreślenie będzie wskazywać, że jest to prywatna zmienna składowa. Jak powiedział Gollum, będzie to zależeć od zespołu.

Wiele osób lubi mieć pola osobiste z przedrostkiem podkreślonym. To tylko konwencja nazewnictwa.
„Oficjalne” konwencje nazewnictwa języka C # narzucają proste nazwy małymi literami (bez podkreślenia) dla pól prywatnych.
Nie znam standardowych konwencji C ++, chociaż podkreślenia są bardzo szeroko stosowane.

Jest to po prostu konwencja, której niektórzy programiści używają, aby wyjaśnić, kiedy manipulujesz elementem klasy lub inną zmienną (parametry lokalne funkcji itp.). Inną konwencją, która jest również szeroko stosowana w przypadku zmiennych składowych, jest poprzedzanie nazwy przedrostkiem „m_”.
Zresztą to tylko konwencje i nie znajdziesz dla nich jednego źródła. To kwestia stylu, a każdy zespół programistyczny, projekt lub firma ma swój (a nawet nie).

Istnieje uzasadniony powód, aby używać go w C #:
https://connect.microsoft.com/ ... in1.0
jeśli kod również musi być rozszerzalny z VB.NET.
(W przeciwnym razie nie zrobiłbym tego.)
Ponieważ VB.NET nie rozróżnia wielkości liter, w tym kodzie nie ma łatwego sposobu na uzyskanie dostępu do chronionego elementu

field

:

public class CSharpClass

{

 protected int field;

 public int Field { get { return field; } }

}

Na przykład. spowoduje to dostęp do właściwości pobierającej, a nie pola:

Public Class VBClass

 Inherits CSharpClass Function Test() As Integer

 Return Field

 End FunctionEnd Class

Heck, nie mogę nawet napisać

field

małymi literami - VS 2010 po prostu to naprawia.
Aby była łatwo dostępna dla klas pochodnych w VB.NET, musisz wymyślić inną konwencję nazewnictwa. Przedrostek podkreślenia jest prawdopodobnie najmniej inwazyjny i najbardziej „historycznie akceptowany” z nich.

Teraz notacja używająca „this”, jak w this.foobarbaz, jest akceptowalna dla zmiennych składowych klasy C #. Zastępuje starą notację „m_” lub po prostu „__”. Dzięki temu kod jest bardziej czytelny, ponieważ nie ma wątpliwości, co to za link.

Stare pytanie, nowa odpowiedź (C #).
Innym zastosowaniem podkreślenia dla C # jest użycie ASP NET Core DI (iniekcja zależności). Prywatne zmienne klasy

readonly

, które zostały przypisane do wprowadzonego interfejsu w czasie kompilacji, muszą zaczynać się od podkreślenia. Wydaje mi się, że jest to dyskusja o tym, czy używać podkreślenia dla każdego prywatnego członka klasy (chociaż sam Microsoft podąża za tym), ale jest to określone.

private readonly ILogger<MyDependency> _logger;public MyDependency(ILogger<MyDependency> logger)

{

 _logger = logger;

}

Ta konwencja nazewnictwa jest przydatna podczas czytania kodu, zwłaszcza kodu, który nie jest Twoim własnym. Silna konwencja nazewnictwa pomaga wskazać, gdzie określony członek jest zdefiniowany, jakiego rodzaju jest członkiem itd. Większość zespołów programistycznych przyjmuje prostą konwencję nazewnictwa i po prostu poprzedza pola członków podkreśleniami (

_fieldName

) . W przeszłości stosowałem następującą konwencję nazewnictwa dla języka C # (która jest oparta na konwencjach Microsoftu dla kodu platformy .NET, którą można zobaczyć w programie Reflector):

Pole instancji:

m_fieldName


Pole statyczne:

s_fieldName


Członek publiczny/chroniony/wewnętrzny:

PascalCasedName()


Członek prywatny:

camelCasedName()
Pomaga ludziom bardzo szybko zrozumieć strukturę, użycie, dostępność i układ elementów podczas czytania nieznanego kodu.