Czy ktoś może mi wyjaśnić konwencję kodowania C #?

Niedawno zacząłem pracować z Unity3D i przede wszystkim pisać skrypty w języku C #. Jak zwykle programuję w Javie, różnice nie są zbyt duże, ale wciąż odwoływałem się do kursu awaryjnego, aby upewnić się, że jestem na dobrej drodze.

Jednak moją największą ciekawością z C # jest to, że używa dużej litery pierwszej nazwy swoich metod (np. Java: getPrime()C #: GetPrime()aka: Pascal Case?). Czy jest na to dobry powód? Rozumiem ze strony kursu awaryjnego, że przeczytałem, że najwyraźniej jest to konwencja dla .Net i nie mam możliwości, aby ją kiedykolwiek zmienić, ale jestem ciekawy, dlaczego tak się stało w przeciwieństwie do normalnej (względnej?) Wielbłąda które, powiedzmy, używa Java.

Uwaga: Rozumiem, że języki mają własne konwencje kodowania (wszystkie metody Pythona są pisane małymi literami, co ma zastosowanie również w tym pytaniu), ale nigdy tak naprawdę nie rozumiem, dlaczego nie jest sformalizowane w standard.

c# coding-standards

— Ahodder
źródło

I naprawdę nie sądzę, że można spojrzeć na camelCasei PascalCasei underscore_casei powiedzieć, że jeden z nich jest normalne (nawet stosunkowo normalny), a inni nie. Jak powiedział @dasblinkenlight, jest to arbitralny wybór. Jedyną rzeczą, która sprawia, że myślisz, że konwencja C # jest niezwykła, jest to, że „normalnie programujesz w Javie”, a zatem jesteś przyzwyczajony do arbitralnego wyboru dla Javy.

— Carson63000,

Zamiast tego użyj JavaScript ... dla Unity3D :)

— Lipis,

@Lipis Dlaczego za - inny niż osobisty gust? ;-)

— ahodder

@AedonEtLIRA całkowicie osobista .. nieważne :) Ciesz się Unity bez względu na język .. skończysz używać ..

— Lipis

@Lipis Jak dotąd jest świetnie. Mnóstwo dzwonków i gwizdków, a ja jeszcze nie zrzuciłem na to pieniędzy. Ale wolę ustrukturyzowany styl C # (c / c ++) i java.

— ahodder

Odpowiedzi:

Konwencje nazewnictwa reprezentują arbitralne wybory ich wydawcy. W samym języku nic nie stoi na przeszkodzie, aby nazwać metody tak, jak robisz to w Javie: dopóki pierwszy znak to litera / podkreślnik, a wszystkie pozostałe znaki to litery, cyfry lub podkreślenia, C # nie będzie skarżyć się. Jednak biblioteki klas dostarczane z platformą .NET są zgodne z konwencją wewnętrznie przyjętą przez Microsoft. Microsoft opublikował również te wytyczne , aby inni mogli zdecydować się na ich zastosowanie również w bibliotekach własnych klas. Mimo, że Twoim wyborem jest postępowanie zgodnie z wytycznymi Microsoft lub ignorowanie ich, zapoznanie się z Twoim kodem przez innych może przyspieszyć, jeśli zastosujesz te same wytyczne nazewnictwa.

— dasblinkenlight
źródło

Jednak konwencja zwykle ma uzasadnienie i kiedy czytam „Czy jest ku temu dobry powód?” Rozumiem to jako pytanie o DLACZEGO nie CO.

— greenoldman

Pascal dla członków publicznych / wewnętrznych / statycznych i wszystkich metod. Wielbłąd dla osób prywatnych. Pomaga rozróżnić zakres tokena podczas jego skanowania. Słowo thiskluczowe robi to samo. Wybory stylu są praktyczne, nawet jeśli mogą wydawać się obce

— Gusdor,

Być może z powodu wpływu Pascala / Delphi. Twórca C # i Delphi był w końcu tą samą osobą (Anders Hejlsberg).

Konwencje kodowania Delphi w zasadzie są w tym aspekcie takie same jak C #; patrz http://www.econos.de/delphi/cs.html#ObjectPascal_Procedures lub http://wiki.delphi-jedi.org/index.php?title=Style_Guide#Method_Naming - przypadek?

— Konrad Morawski
źródło

+1 za to, ponieważ daje to, co może być faktycznym powodem, dla którego dokonano tego konkretnego arbitralnego wyboru dla C #.

— Maximus Minimus

Oprócz innych udzielonych odpowiedzi, posiadanie wielbłąda dla metod oznacza, że mogą one powodować konflikty z nazwami członków prywatnych, parametrami i zmiennymi metod, które używają wielkości wielbłąda do nazywania. W Javie (i C # 1.0) nie jest to zbyt powszechne, ponieważ korzystanie z funkcji delegowania jest niewygodne i rzadkie. We współczesnym języku C # nie jest to dość powszechne , ale nie jest też niespotykane.

— Telastyn
źródło

Podkreślenia nie należy używać w prywatnych polach C # (patrz blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx , np.), Ale jest on kontrowersyjny i często znajduje się.

— Jens

poleganie na obudowie w celu rozróżnienia konstrukcji językowych jest naprawdę złym pomysłem, niezależnie od tego, czy język na to pozwala, czy nie.

— gbjbaanb

@Telastyn to stwierdzenie jest dość szokujące. Większość bibliotek klas .NET korzysta z tej konwencji.

— MattDavey,

@Dunk, jak to nagle moja konwencja? Po prostu komentowałem, nie mam zdania na ten temat, tak czy inaczej :)

— MattDavey

@MarjanVenema: nie jestem pewien, o czym mówisz, ale w C # rozróżniana jest wielkość liter i na pewno możesz mieć kolizje między członkami o podobnych nazwach. To staje się zabawne i ekscytujące, gdy masz rzeczywiste języki INsensitive, takie jak VB.NET, z którymi pracujesz na poziomie biblioteki.

— Wyatt Barnett