Dlaczego Microsoft sprawił, że parametry, zmienne lokalne i pola prywatne mają tę samą konwencję nazewnictwa nazw?

18

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?

Vaccano
źródło
10
Co masz na myśli mówiąc „nie możesz wiedzieć, o którym mówisz”? Oczywiście, że tak - zakres.
Thomas Owens
2
To wytyczne wydają się nieaktualne, domyślnie resharper (który stał się czymś w rodzaju przewodnika po stylu defacto) zaleca prefiksowanie prywatnych pól znakiem podkreślenia, co i tak zawsze robiłem.
25
@kekekela: To absolutnie nieaktualne; StyleCop wyraźnie oznaczy wszystkie wystąpienia zmiennych składowych zaczynające się od znaku podkreślenia. Szczerze mówiąc, podkreślenie jest bezcelowe i denerwujące, ponieważ obudowa przekazuje dokładnie te same informacje. Jeśli chcesz wyraźnie określić zakres, przypisz prefiks za pomocą this..
Aaronaught
12
@Aaronaught Znalazłem kilka zbędnych „tego”. rozrzucone po moim kodzie bez sensu i irytujące.
12
@kekekela: Jedyne miejsce ja kiedykolwiek znajdę się konieczności zrobić to w konstruktorze, aw konstruktora to ma sens, ponieważ jesteś dosłownie przechodzącą w wartości, które zainicjować pól członkowskich ( 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.
Aaronaught

Odpowiedzi:

14

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.

Dave
źródło
1
Myślę, że pomyliłeś „zgodny z CLR” z „zgodny z CLS”. Gdyby coś nie było zgodne z CLR, nie skompilowałoby się. CLS jest tylko ostrzeżeniem, że może nie być kompatybilny z innymi językami i zasadniczo dotyczy tylko członków publicznych (technicznie rzeczy widoczne na zewnątrz zespołu).
Joel C
@Joel - Masz rację. Pytanie to dotyczy: stackoverflow.com/questions/1195030/...
dave
2
Nadal używam przedrostka „m_” ...
CesarGon
4
+1 „dla ciebie nie musisz robić wszystkiego, co nakazuje ci MS”. Pomyślcie sami!
gbjbaanb
1
To nie jest zgodne z CLS, jeśli pole jest protected, nieprivate
Rachel
9

locala parameterzmienne są nazywane w ten sam sposób, ponieważ ich zakres jest taki sam

Jeś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 ++

Nazwy zaczynające się od podwójnego podkreślenia lub podkreślenia i dużej litery są zastrzeżone do implementacji (kompilator, biblioteka standardowa) i nie należy ich używać (np. __Reserved lub _Reserved).

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.

Rachel
źródło
2
Dobra uwaga na temat parametrów i zmiennych lokalnych o tym samym zakresie (+1). Nikt inny o tym nie wspominał. Następstwem jest to, że jeśli potrzebujesz zmiennej lokalnej o tej samej nazwie co parametr, możesz po prostu użyć parametru. Osobiście uważam podkreślenie za brzydkie i nieprecyzyjne. Natomiast thiszdecydowanie odnosi się do bieżącego obiektu. Nie rozumiem nienawiści do this. Czy dlatego, że jest źle zrozumiany?
Jason S
4

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ą _lub m_, 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:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Bez żadnych innych wtyczek Visual Studio domyślnie pomoże ci z Intellisense:

zrzut ekranu

(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.

Adam Lear
źródło
Mówiąc trochę dalej 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ędne this. 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.
Jason S,
4

Dlaczego standard Microsoftu nie wyróżniał ich?

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.

camelCasingjest dla nazw parametrów.
PascalCasingdotyczy 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, np IOStream.

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.

Tangurena
źródło
4
Czy chciałbyś podsumować tych z nas, którzy nie są właścicielami książki?
Kramii Reinstate Monica
Zgadzam się z Kramii. Podsumowanie byłoby świetne!
Vaccano
@Kramil, Vaccano, Wygląda na to, że będę musiał ponownie sprawdzić to w bibliotece. Zwykle robię to tylko przy rozpoczynaniu nowej pracy, a dyskusje dotyczą standardów nazewnictwa i kodowania.
Tangurena,
1
lol, więc „Nie można polegać na różnicach w przypadku samej rozróżnienia przedmiotów”, a następnie mówi, że należy użyć camelCase lub PascalCase do rozróżnienia przedmiotów.
gbjbaanb
1

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ć, thisaby 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.

Łup
źródło
0

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 znakiem v_.

FrustratedWithFormsDesigner
źródło
0

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

ElGringoGrande
źródło
2
Tak, ale MS przestało używać m dla członków, do czego zmierza PO.
Christopher Bibbs,
„Większość firm” nie obejmuje Microsoft, czyli firmy, której dotyczy to pytanie.
Aaronaught
1
Nie zdawałem sobie sprawy, że Micrsoft MSDN jest dla wewnętrznych standardów kodowania w Microsoft.
JeffO
1
@JeffO: Masz rację, nie, ale ich wewnętrzne wytyczne kodowania mówią to samo .
Aaronaught
0

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).

JaCraig
źródło
1
1) język węgierski nie został wymyślony przez Microsoft, oraz 2) „węgierski”, o którym mówisz, jest typem węgierskim niż semantycznym węgierskim.
Aaronaught
Nigdy nie mówiłem, że Microsoft to wymyślił. Powiedziałem, że wymyślił to Charles Simonyi (w szczególności notacja węgierska dotycząca aplikacji). Microsoft pchnął go mocno, ale nigdy nie powiedziałem, że go stworzyli (w rzeczywistości powiedziałem, że nie jestem pewien, czy stworzył go podczas swoich dni Xerox lub Microsoft). Podałem to jako przykład czegoś, co duża firma (Microsoft) zaproponowała jako sposób, w jaki należy to zrobić. Chodzi mi o to, że OP nie powinien martwić się konwencjami nazewnictwa, że ​​firma, dla której nie pracuje, twierdzi, że jest „właściwą drogą” (chyba że pracuje dla Microsoftu, w którym to przypadku powinno go to obchodzić).
JaCraig,
[potrzebne źródło]
Aaronaught
1
Tak, nie potrzebowaliśmy cytowania na temat węgierskiej notacji. [Potrzebne źródło] dotyczy wszystkich podejrzanych roszczeń zawartych w odpowiedzi.
Aaronaught