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

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?

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.

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.

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:

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

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.

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.

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

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

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