Jaka filozofia / rozumowanie kryje się za nazwami metod Casing w Pascalu?


22

Właśnie zaczynam się uczyć języka C #. Pochodząc z tła w Javie, C ++ i Objective-C, uważam, że pascal C # w swoich nazwach metod jest raczej unikalny i na początku trudno się do niego przyzwyczaić. Jakie jest tego rozumowanie i filozofia?

Zgaduję, że to ze względu na właściwości C #. W przeciwieństwie do Objective-C, gdzie nazwy metod mogą być dokładnie takie same jak zmienne instancji, nie jest tak w przypadku C #. Sądzę, że jednym z celów właściwości (podobnie jak w przypadku większości obsługiwanych języków) jest uczynienie właściwości naprawdę nierozróżnialnymi od zmiennych i metod. Tak więc można mieć „int x” w języku C #, a odpowiednia właściwość staje się X. Aby zapewnić, że właściwości i metody są nierozróżnialne, wszystkie nazwy metod, które, jak sądzę, powinny zaczynać się również od dużej litery. (To tylko moja hipoteza oparta na tym, co wiem o C # do tej pory - wciąż się uczę). Jestem bardzo ciekawy, jak powstały te dziwne wytyczne (biorąc pod uwagę, że „

(EDYCJA: Przez obudowę Pascala mam na myśli PascalCase (która jest w zasadzie camelCase, ale zaczyna się od dużej litery). Nazwy metod zwykle zaczynają się od małej litery w większości języków)


Jeśli zobaczysz, że wszyscy członkowie pewnej rodziny mają wszystkie ściany we wszystkich swoich domach pomalowane dziwnymi insygniami, czy byłbyś ciekawy, dlaczego zrobili to tak dziwne?
Nocturne

1
Jak myślisz, dlaczego nazywa się to sprawą Pascala ?
R. Martinho Fernandes,

1
@Martinho Fernandes to standardowa nazwa tego stylu, sprawdź Google
Andrey

1
@Nocturne - Tak. Byłbym ciekawy :)
Joel Etherton

1
„Nazwy metod zaczynają się od małej litery w większości języków” są z mojego doświadczenia fałszywe. Konwencje rozpoczynające się od dużej litery - z separatorem słów lub bez podkreślenia - są dość powszechne, choć niekoniecznie w oficjalnych wytycznych językowych. Większość standardów językowych nie ma żadnych oficjalnych przewodników po stylu. W każdym razie całkiem sporo języków (głównie starszych) ignoruje wielkość liter i często stosuje konwencję pisaną małymi literami, ponieważ zasada „nie naciskaj” to najbardziej leniwa zasada, która oznacza, że ​​pisownia liter o różnej wielkości liter nie jest traktowana jako to samo zamieszanie .
Steve314,

Odpowiedzi:


27

To kwestia gustu. Ktoś kiedyś zdecydował się na styl Pascal dla nazw i stał się standardem.

Zgaduję, że to Anders Hejlsberg , architekt Delphi, następca Pascala. Styl obudowy jest taki sam, jak w języku C #.


to będzie moja odpowiedź. : P
DevSolo

@DevSolo przepraszam, zacząłem pisać odpowiedź, gdy pytanie było na Stackoverflow :)
Andrey

Myślę, że korzenie sięgają jeszcze głębiej w historię starożytną - patrz moja odpowiedź poniżej :)
davka

20

Jeśli pytasz o powody, oto jeden prosto z pyska konia:

Historia wokół Pascala Casinga i artykułu Camel Casing autorstwa Brada Abramsa na blogach MSDN

W początkowej fazie projektu mieliśmy setki godzin debaty na temat stylu nazewnictwa. Aby ułatwić te debaty, stworzyliśmy szereg terminów. Ponieważ Anders Heilsberg (oryginalny projektant Turbo Pascal ) jest kluczowym członkiem zespołu projektowego, nic dziwnego, że wybraliśmy termin Pascal Casing dla stylu obudowy spopularyzowanego przez język programowania Pascal ...

Konwencja Pascal Casing zawiera pierwszy znak każdego słowa (łącznie z akronimami o długości dwóch liter) ...

A oto wytyczne projektowe: Wskazówki projektowe dla programistów bibliotek klas

Te wytyczne mają pomóc projektantom bibliotek klas w zrozumieniu kompromisów między różnymi rozwiązaniami. Mogą wystąpić sytuacje, w których dobry projekt biblioteki wymaga naruszenia niniejszych wytycznych dotyczących projektowania. Takie przypadki powinny być rzadkie i ważne jest, aby podać solidne uzasadnienie swojej decyzji. Sekcja zawiera wskazówki dotyczące nazewnictwa i użytkowania typów w .NET Framework, a także wytyczne dotyczące wdrażania typowych wzorców projektowych ...


2
TurboPascaljest dzieckiem Philip Kahn(aka Borland), co jest bardzo wygodne dla Microsoftu, aby zapomnieć. Polityka ....
davka

1
Komentarze do pierwszego linku są świetne, lol.
jmq

7

Nie wiem o filozofii, ale obudowa Pascala wydaje się być powszechna na platformach Microsoft od co najmniej dni API Win32.


8
i nadal go nienawidzę, lol.
jmq

2

Nie sądzę, żeby kryła się za tym konkretna filozofia. Potrzebne były wytyczne, które mogły mieć na to wpływ:

  • Chcieli pozbyć się wszelkich zapisów prefiksów (czytaj węgierski tutaj)
  • Chcieli, aby członkowie lokalni / prywatni i członkowie publiczni byli odróżniani po prostu czytając ich nazwiska.
  • Nie chcieli, aby kod C # wyglądał jak kod Java (który mocno wykorzystuje obudowę wielbłąda)

Należy pamiętać, że te wytyczne dotyczące nazewnictwa dotyczą architektury .NET, a nie w szczególności języka C #. W języku VB.NET, w którym nie jest rozróżniana wielkość liter, konwencja pozostaje taka sama, ale nie można jej używać do rozróżniania członków prywatnych i publicznych według przypadków.
R. Martinho Fernandes,

@Martinho: uzgodniono. ale nadal uważam, że to jeden z powodów.
decyklon

7
+1: „Nie chcieli, aby kod C # wyglądał jak kod Java (który intensywnie wykorzystuje obudowę wielbłąda)”: Podejrzewam, że jesteś tutaj!
Giorgio

Ironiczne jest to, że pomimo nienawiści niektórych osób do węgierskiej notacji, Java i C # byłyby prawdopodobnie znacznie lepszymi językami w praktyce, gdyby przyjęły Apps Hungarian (lub inną konwencję nazewnictwa) w celu rozróżnienia pól typu referencyjnego, które „posiadają” zmienny obiekt zidentyfikowane w ten sposób, te, które identyfikują instancję typu mutable, której nigdy nie wolno mutować itp. Nawet jeśli środowisko wykonawcze nie dba o takie rozróżnienia, nie jest możliwe napisanie wydajnego i poprawnego kodu bez wiedzy, jakie zmienne są tego rodzaju.
supercat

0

Nie wiem, czy za obudową kryje się „filozofia”, poza tym, że jest ładna i zwarta i może z łatwością pojawiać się jako wiele słów bez użycia podkreślników.

W ciągu ostatnich kilku dekad istniało wiele odmian obudów. Ich zakres wahał się od bardzo zwięzłego (patrz C i standardowa biblioteka C) do pełnych z podkreśleniami oddzielającymi każde słowo. Chociaż konwencja nazewnictwa bibliotek .NET jest wciąż dość gadatliwa, myślę, że uderza w coś pośredniego, jeśli chodzi o obudowę.


5
nazewnictwo w stylu nie zapomnij!
R. Martinho Fernandes,

@Martinho Fernandes faktycznie w kontekście języków podobnych do c nie jest poprawny.
Andrey

Tak, Lisp bierze pod uwagę białe znaki. (- var1 var2)
Michael K

@Martinho Fernandes: Oczywiście, wymaga to oddzielenia tokenów spacją. Jest to również COBOL-STYLE-NAMING, dzięki czemu jest wspólny dla języków, które najbardziej podziwiam i najmniej podziwiam.
David Thornley,

0

Zgadując dziko (ale nie bez uzasadnienia, IMHO) - projekt C # był nadzorowany przez Niklausa Wirtha , oryginalnego wynalazcę Pascala. Widzisz połączenie? ... :)

Ciekawy # 1: Pozytywnie pamiętam zapowiedź .NET i C # (tak, jestem prehistoryczny ...) oraz to, jak Microsoft chwalił się, mając imię Wirtha na C #. Jednak strony Wikipedii na żadnym z nich (C # i Wirth) nie wspominają o tym.

Curious # 2: Chociaż nazywa się PascalCase, został spopularyzowany przez TurboPascalkompilator (który ostatecznie stał się Borland), a nie sam język.


4
a TurboPascal został wygodnie zaprojektowany i zbudowany przez Andersa Hejlsberga ...
SWeko

3
Anders Hejlsberg był głównym projektantem Delphi w IIRC i dużo pracował nad Turbo Pascal, ale Turbo Pascal nie był pierwotnie jego dzieckiem (był to Philip Kahns). Niklaus Wirth wynalazł oryginalnego Pascala i przeprowadził go przez standaryzację, a następnie zauważył, że standard został w dużej mierze zignorowany. Ponadto, Wirth przeszedł na emeryturę przez prawie całe życie w C #, a wcześniej zaprojektował kilka języków następcy-Pascala (ostatnio Oberon 2), więc wątpię, żeby miał jakikolwiek bezpośredni udział. Microsoft chwalił się głośno, że ma na pokładzie Hejlsberga. Turbo Pascal od samego początku był produktem Borland.
Steve314,

Nie przeszkadza mi obniżenie - mam wystarczającą liczbę punktów na StackOverflow, ale jestem ciekawy powodu
davka
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.