Jakiś czas temu zadałem to pytanie: Jak nazwać zmienne prywatne w języku C #?
W jednej z odpowiedzi wskazano mi stronę MSDN Microsoftu, która pokazuje, że prywatne zmienne / pola powinny mieć następujące nazwy:
private int myInteger;
Ale parametrem byłoby:
void SomeMethod(int myInteger)
a zmienna lokalna wyglądałaby tak:
int myInteger;
Kiedy odniesiesz je w ten sposób
myInteger = 10;
nie możesz wiedzieć, o którym mówisz.
Rozpoczynam teraz nowy projekt, a jeden z moich współpracowników pyta mnie, dlaczego nie robimy czegoś, aby wyróżnić przynajmniej niektóre z nich.
Zastanawiam się nad tym samym. Dlaczego standard Microsoftu nie wyróżniał ich?
.net
coding-standards
naming
Vaccano
źródło
źródło
this.
.this.component = component
). Jeśli znajdziesz gdzie indziej niejednoznaczne zakresy, takie, że masz „garść zbędnych„ tego ”. rozproszone po całym kodzie ”, wtedy masz źle napisany kod.Odpowiedzi:
Oryginalne konwencje nazewnictwa miały przedrostek m_ dla członków klasy, co zostało zredukowane do prostego podkreślenia. Zobaczysz dużo starszego kodu C # Microsoft z prefiksem podkreślenia. Jednak w Tech Ed usłyszałem kiedyś, że wiodący znak podkreślenia nie jest zgodny z CLS. Zakładam, że to jest powód, dla którego przeszli do prostszego schematu „jedno imię dla wszystkich”. Kiedyś (teraz nie jestem pewien) nazwy VB.Net bez rozróżniania wielkości liter również nie były zgodne z CLS.
Dla swojej wartości nadal używam wiodącego podkreślenia dla członków klasy. Mimo że możesz jednoznacznie użyć tego (this.name w przeciwieństwie do name), błędy wciąż się pojawiają.
Nie musisz robić wszystkiego, co nakazuje stwardnienie rozsiane.
źródło
protected
, nieprivate
local
aparameter
zmienne są nazywane w ten sam sposób, ponieważ ich zakres jest taki samJeśli chodzi o zmienne prywatne, istnieją na ten temat różne opinie. Zawsze korzystałem ze znalezionych tu standardów , które określają użycie wiodących
_
przed prywatnymi zmiennymi, chociaż autor twierdzi, że_
jest to nieco kontrowersyjne i że Microsoft go odradza.Wikipedia stwierdza, że w C i C ++
więc być może był to powód, dla którego Microsoft odradzał to, chociaż dość dobrze wiadomo, że wielu deweloperów Microsoft i tak używa
_
przedrostka dla swoich prywatnych zmiennych.źródło
this
zdecydowanie odnosi się do bieżącego obiektu. Nie rozumiem nienawiści dothis
. Czy dlatego, że jest źle zrozumiany?Nie mogę ci powiedzieć z całą pewnością, dlaczego nie wyróżnili ich. Jest prawdopodobne, że nikt nie może, chyba że ktoś, kto brał udział w tworzeniu standardów, nie zobaczy tego pytania.
Wiele osób tworzy własne konwencje, poprzedzając zmienne instancji za pomocą
_
lubm_
, ale tak naprawdę nie sądzę, żeby to miało znaczenie. Możesz wnioskować wiele z kontekstu, a IDE są obecnie wystarczająco inteligentne, aby ci pomóc. Na przykład Visual Studio z dodatkiem ReSharper pokaże zmienne lokalne i zmienne instancji w różnych kolorach.Jeśli naprawdę ważne jest, aby rozróżnić dwa zakresy, możesz użyć
this.
przedrostka, aby odwołać się do zmiennej instancji:Bez żadnych innych wtyczek Visual Studio domyślnie pomoże ci z Intellisense:
(Wyskakujące okienko może nadal być tam zaprojektowane przez ReSharper, ale ReSharper nie dodaje niczego do funkcji wbudowanego Intellisense, więc chociaż podstawowy może wyglądać nieco inaczej, nadal będzie miał obie opcje. )
Możesz także użyć narzędzi do analizy kodu, takich jak FxCop i StyleCop, aby pomóc w wychwyceniu potencjalnych problemów związanych ze zmiennymi nazwami i zakresem.
źródło
this
, zawsze wolęthis
, ponieważ zdecydowanie odnosi się do bieżącej instancji, niezależnie od tego, w którym domu się znajdujesz, więc jest precyzyjny. Konwencje podkreślenia lub podkreślenia są po prostu - konwencjami, które mogą, ale nie muszą, odwoływać się do zmiennych instancji i są przez nie zbędnethis
. Jedynym miejscem, w którym uważam podkreślenie za przydatne, jest rozróżnianie wielkości liter w nazwach obiektów i klas w VB bez rozróżniania wielkości liter. Ale to zupełnie inna historia.Ludzie w Microsoft napisali książkę zatytułowaną Framework Design Guidelines, która wyjaśnia wiele konwencji, w tym dlaczego niektóre rzeczy były wielbłądami , a inne pascalami .
Edytuj (dodając szczegóły z książki):
W książce wspominają o robieniu badań użyteczności, a także o niektórych lekcjach wyciągniętych z przejęcia grupy Turbo Pascal. Ponadto, chociaż nie we wszystkich językach rozróżniana jest wielkość liter (na przykład VB), inne są (na przykład C #), więc należy zachować spójność w nazwie. Aby odróżnić przedmioty, nie można polegać na różnicach. Jeśli pozostanie się przy konwencjach używanych przez resztę frameworka, doprowadzi to do mniejszego zamieszania przez deweloperów.
Rozdział 3, Wskazówki dotyczące nazewnictwa.
Sekcja 3.1 to konwencje wielkich liter.
camelCasing
jest dla nazw parametrów.PascalCasing
dotyczy nazw, typów i nazw członków. W przypadku gdy 2-literowe akronimy są częścią nazwy, należy je używać wielkich liter, npIOStream
.Sekcja 3.5 obejmuje klasy nazewnictwa, struktury i interfejsy.
Podrozdział 3.6 zawiera opis typów członków.
Sekcja 3.7 zawiera parametry nazewnictwa.
źródło
Ponieważ są one dość wyraźne, ponieważ zależą od kontekstu, w którym zostały napisane.
Na przykład, czy używałeś kiedyś parametru jako zmiennej członka? Czy zmienna lokalna jako parametr? A co ze zmienną składową jako lokalną?
Wszystkie zmienne składowe znajdują się w „ciele” klasy. Naprawdę nie kupuję argumentu, że musisz prefiksować członka, gdy możesz go użyć,
this
aby odróżnić go od zmiennej lokalnej o podobnej nazwie, w przeciwnym razie nie jest to konieczne.Zmienna lokalna jest również definiowana tylko w zakresie metody lub w zakresie bloku kodu.
Parametr jest zawsze zdefiniowany w podpisie metody.
Jeśli wszystkie te zmienne zostaną pomieszane lub zmieszane, to naprawdę powinieneś pomyśleć więcej o projekcie kodu, aby uczynić go bardziej czytelnym lub wykrywalnym. Nadaj im lepsze i bardziej opisowe nazwy niż
myInteger
.źródło
Nie mogę odpowiedzieć na twoje pytanie dotyczące standardów Microsoft. Jeśli chcesz się standardem odróżnić te rzeczy, średnia Zastosowanie I dla parametrów PL / SQL jest poprzedzenie nazwę parametru z
in_
,out_
,io_
, dla in-, ambulatoryjnych, aw-ambulatoryjnych parametrów. Zmienne lokalne dla funkcji są poprzedzone znakiemv_
.źródło
Większość firm, które znam, ma standardy kodowania, które określają znak podkreślenia lub małą literę m (dla „członka” zakładam) jako przedrostek dla ich zmiennych członkowskich.
Więc
_varName
lub
mVarName
źródło
Tak jak zauważyli inni ludzie, zazwyczaj można stwierdzić, który z nich jest używany na podstawie zakresu. W rzeczywistości nie możesz mieć parametru i zmiennej lokalnej w tym samym zakresie, a jeśli chcesz zmiennej prywatnej, po prostu użyj this.myInteger. Więc nie sądzę, że Microsoft martwił się tym zbytnio, ponieważ możesz łatwo rozróżniać między nimi, jeśli chcesz.
Ale powiedziawszy to, jestem nieco zaskoczony, że nikt jeszcze tego nie powiedział, ale zapomnij o Microsoft i ich konwencjach nazewnictwa (no cóż, ktoś mógł już to powiedzieć, ponieważ musiałem pobiec na spotkanie i zostawić to otwarte bez poddawania się to). Notacja węgierska była również konwencją nazewnictwa zapoczątkowaną w firmie Microsoft (a może Xerox? Nigdy nie pamiętam, kiedy wymyślił ją Simonyi). Nie mogę myśleć o nikim, kogo znam, co do dziś nie przeklina nazwy węgierskiej notacji. W miejscu, w którym pracowałem, poczuliśmy się tak zirytowani, że opracowaliśmy własny standard, z którego korzystaliśmy wewnętrznie. To miało dla nas więcej sensu i nieco przyspieszyło naszą pracę (w rzeczywistości było dość blisko tego, co sugeruje teraz Microsoft, ale wszystko było przypadkiem pascal, z wyjątkiem zmiennych prywatnych).
Biorąc to pod uwagę, nowszy standard, który stosuje Microsoft (połączenie obudowy wielbłąda i skrzynki pascala) nie jest taki zły. Ale jeśli ty i twoi współpracownicy wam się nie podoba, wymyślcie własny zestaw standardów (najlepiej wspólnie). Zależy to oczywiście od tego, czy Twoja firma ma już zestaw standardów. Jeśli tak, trzymaj się ich. W przeciwnym razie wymyśl, co działa dla ciebie i twoich współpracowników. Po prostu zachowaj logikę.
Ponieważ Aaronaught poprosił o cytowanie o Charlesie Simonyi i notacji węgierskiej: http://en.wikipedia.org/wiki/Charles_Simonyi
http://en.wikipedia.org/wiki/Hungarian_notation
http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx
http://ootips.org/hungarian-notation.html
http://www.hitmill.com/programming/vb/Hungarian.html
http://web.mst.edu/~cpp/common/hungarian.html
Dwa ostatnie to tylko przykłady węgierskiej notacji, a link Ootips to tylko kilka cytatów dotyczących niektórych opinii na ten temat. Zauważ, że istnieje także system Notacji Węgierskiej, ale o ile wiem, popularność zyskała także od programistów Microsoft (chociaż w przeciwieństwie do Simonyi dla wersji aplikacji, nie wiem kto).
źródło