Mam wątpliwości co do CamelCase. Załóżmy, że masz ten akronim:Unesco = United Nations Educational, Scientific and Cultural Organization.
Powinieneś napisać: unitedNationsEducationalScientificAndCulturalOrganization
Ale co, jeśli musisz napisać akronim? Coś jak:
getUnescoProperties();
Czy dobrze jest tak to napisać? getUnescoProperties() OR getUNESCOProperties();
coding-style
camelcasing
acronym
gal007
źródło
źródło
get_unesco_properties
lubget_u_n_e_s_c_o_properties
?Odpowiedzi:
Niektóre wytyczne , o których pisał Microsoft,
camelCase
to:Podsumowując:
Kiedy używasz skrótu lub akronimu o długości dwóch znaków, umieść je wszystkie wielkimi literami;
Gdy akronim jest dłuższy niż dwa znaki, użyj kapitału dla pierwszej postaci.
Tak więc w twoim konkretnym przypadku
getUnescoProperties()
jest poprawne.źródło
ID
zamiast tegoId
(którego używam / widzę wszędzie)XMLHttpRequest()
pierwotnie pochodzą od Microsoft.Istnieje uzasadniona krytyka porady Microsoft z zaakceptowanej odpowiedzi.
playerID
vsplayerId
vsplayerIdentifier
.USTaxes
vsusTaxes
USID
vsusId
(lubparseDBMXML
w przykładzie Wikipedii).Więc opublikuję tę odpowiedź jako alternatywę dla odpowiedzi zaakceptowanej. Wszystkie akronimy należy traktować konsekwentnie; akronimy należy traktować jak każde inne słowo. Cytując Wikipedię :
Więc ponownie: pytanie OP, zgadzam się z przyjętą odpowiedzią; to jest poprawne:
getUnescoProperties()
Ale myślę, że doszedłbym do innych wniosków w tych przykładach:
US Taxes
→usTaxes
Player ID
→playerId
Głosuj więc na tę odpowiedź, jeśli uważasz, że dwuliterowe akronimy należy traktować jak inne akronimy.Camel Case to konwencja, a nie specyfikacja. Myślę, że popularne reguły opinii.( EDYCJA: Usunięcie sugestii, że głosowanie powinno rozstrzygać tę kwestię; jak mówi @Brian David; Stack Overflow nie jest „konkursem popularności”, a pytanie to zostało zamknięte jako „oparte na opiniach”)
Chociaż wielu woli traktować akronimy jak jakikolwiek inny wyraz, bardziej powszechną praktyką może być wstawianie akronimów na wielkie litery (nawet jeśli prowadzi to do „obrzydliwości”)
Inne zasoby:
źródło
USTaxes
iPlayerId
; camelCase:usTaxes
iplayerId
. 3) Będzie toUSId
w PascalCase,usId
w camelCase iparseDbmXml
w camelCase.InIN(item)
vsInIn(item)
(wskazówka: IN to cal (y)). LubIDById(id)
kontraIdById(id)
nauka kontekstowa (wskazówka: ID oznacza chorobę zakaźną). „Dwa znaki długie” - w jakim kontekście?Po pierwsze, muszę wyjaśnić, że nie jestem rodzimym językiem angielskim , więc moje twierdzenie na temat gramatyki języka angielskiego może być po prostu błędne. Jeśli odkryjesz takie błędy, daj mi znać, a będę bardzo wdzięczny.
Najlepszą praktyką dla akronimu byłoby unikanie akronimów w jak największym stopniu. W każdym razie tak nie jest, ponieważ akronim
UNESCO
jest bardziej znany niż pełna nazwaUnitedNationsEducationalScientificAndCulturalOrganization
.Zatem myślę, że
UNESCO
ma to większy sens niż to,Unesco
że po prostu jest bliżej prawdziwej formy życia, tak dobrze znanej. Miałem problem z ustaleniem, co takUnesco
naprawdę oznacza to słowo .Jako kolejny przykład zastanów się
Arc
. To brzmi jak zakręt wokół koła, ale w Rust oznacza toAtomically Reference Counted
. Gdyby zostało napisane w ten sposóbARC
, przynajmniej czytelnicy zrozumieliby, że słowo jest akronimem czegoś innego niż rodzajem krzywej.Nowoczesne programy są pisane głównie dla czytelników. Następnie te reguły nazewnictwa muszą być ustawione dla czytelności dla ludzi, a nie dla przetwarzania lub analizy maszynowej.
W tej perspektywie, tracimy pewną czytelność przy użyciu
Unesco
ponadUNESCO
zyskując jednocześnie nic.A w innych przypadkach myślę, że przestrzeganie zwykłych angielskich reguł akronimowych (lub konwencji) jest wystarczające dla większości przypadków dla najlepszej czytelności .
źródło
Aby przekonwertować na CamelCase, istnieje również (prawie) deterministyczny algorytm wielbłąda Google'a :
W poniższych przykładach „Żądanie HTTP HTTP” zostało poprawnie przekształcone na XmlHttpRequest, XMLHTTPRequest jest niepoprawny.
źródło
getUnescoProperties()
powinno być najlepszym rozwiązaniem ...Jeśli to możliwe, postępuj zgodnie z czystym
camelCase
, a jeśli masz akronimy, po prostu pozwól im pisać dużymi literami, jeśli to możliwe, w przeciwnym raziecamelCase
.Ogólnie w OO programowanie zmiennych powinno zaczynać się od małej litery (
lowerCamelCase
), a klasa powinna zaczynać się od dużej litery (UpperCamelCase
).W razie wątpliwości po prostu bądź czysty
camelCase
;)parseXML
jest w porządku,parseXml
teżcamelCase
XMLHTTPRequest
powinny byćXmlHttpRequest
lubxmlHttpRequest
nie mogą iść z kolejnymi dużymi akronimami, to zdecydowanie nie jest jasne dla wszystkich przypadków testowych.np jak czytasz te słowa
HTTPSSLRequest
,HTTP + SSL
alboHTTPS + SL
(to nic nie znaczy, ale ...), w tym przypadku obserwacji camel sprawa konwencji i pójść nahttpSslRequest
lubhttpsSlRequest
, być może nie ma już ładne, ale jest zdecydowanie bardziej wyraźne.źródło
HTTPSSL
przykład, chociaż SL nic nie znaczy, a może coś takiego jak HTTPSSHTunnel? Czy to HTTPS + SH (powłoka) czy HTTP + SSH? Konwencja Google jest zdecydowanie mniej dwuznaczna.W github znajduje się przewodnik po stylach JavaScript airbnb z dużą ilością gwiazdek (~ 57,5 tys. W tej chwili) oraz przewodniki na temat akronimów, które mówią:
źródło
XMLHTTPRequest
jest o wiele lepiej czytelny niżXmlHttpRequest
, prawda?httpRequests
jest uważany za dobry, aleHttpRequests
zły. zgodnie z tą zasadą, dla żądania HTTP HTTP powinno byćxmlhttpRequest
???xmlHttpRequest
jest bardziej czytelny niżXMLHTTPRequest
moim zdaniem.Obecnie korzystam z następujących zasad:
Sprawa kapitał dla akronimów:
XMLHTTPRequest
,xmlHTTPRequest
,requestIPAddress
.Sprawa Camel na skróty:
ID[entifier]
,Exe[cutable]
,App[lication]
.ID
jest wyjątkiem, przepraszam, ale prawda.Kiedy widzę wielką literę, zakładam akronim, tzn. Osobne słowo dla każdej litery. Skróty nie mają osobnych słów dla każdej litery, więc używam wielbłąda.
XMLHTTPRequest
jest niejednoznaczny, ale jest to rzadki przypadek i nie jest tak bardzo niejednoznaczny, więc jest w porządku, zasady i logika są ważniejsze niż piękno.źródło
Przewodnik po stylu JavaScript Airbnb mówi o tym trochę . Gruntownie:
Ponieważ zwykle czytam wielką literę jako klasę, zwykle tego unikam. Na koniec dnia wszystko jest preferencyjne.
źródło
Oprócz tego, co powiedział @valex, chcę podsumować kilka rzeczy z podanymi odpowiedziami na to pytanie.
Myślę, że ogólna odpowiedź brzmi: zależy to od używanego języka programowania.
C Sharp
Microsoft napisał kilka wytycznych, w których wydaje się, że
HtmlButton
jest to właściwy sposób na nazwanie klasy dla tych przypadków.JavaScript
JavaScript ma pewne zmienne globalne z akronimami i używa ich wszystkich wielkimi literami (ale zabawnie, nie zawsze konsekwentnie) oto kilka przykładów:
encodeURIComponent
XMLHttpRequest
toJSON
toISOString
źródło
onerror
.zrzeczenie się: Angielski nie jest moim tonem macierzystym. Ale myślałem o tym problemie od dłuższego czasu, szczególnie gdy korzystałem z węzła (styl camelcase) do obsługi bazy danych, ponieważ nazwy pól tabeli powinny być wężowe, oto moja myśl:
Istnieją dwa rodzaje „akronimów” dla programisty:
tmc and textMessageContainer
, który zwykle pojawia się jako zmienna lokalna.W świecie programowania wszystkie akronimy w języku naturalnym należy traktować jak słowo , przyczyny są następujące:
kiedy programujemy, powinniśmy nazwać zmienną albo w stylu akronimowym, albo nie-akronimowym. Tak więc, jeśli mamy wymienić getUNESCOProperties funkcyjne, to znaczy UNESCO jest skrótem (w przeciwnym wypadku nie powinny być wszystkie litery wielkie), ale widocznie,
get
iproperties
nie są akronimy. dlatego powinniśmy nazwać tę funkcję albo gunescop, albo getUnitedNationsEducationalScientificAndCulturalOrganizationProperties , oba są niedopuszczalne.język naturalny ewoluuje nieustannie, a dzisiejsze akronimy staną się jutro słowami , ale programy powinny być niezależne od tego trendu i trwać wiecznie.
tak przy okazji, w najczęściej głosowanej odpowiedzi IO to akronim w języku komputerowym (skrót od InputOutput), ale nazwa mi się nie podoba, ponieważ uważam, że akronim (w języku komputerowym) powinien być używany tylko do nazwania zmienna lokalna, ale klasa / funkcja najwyższego poziomu, dlatego zamiast IO należy użyć InputOutput
źródło
UNESCO jest szczególnym przypadkiem, ponieważ zwykle (po angielsku) jest czytane jako słowo, a nie akronim - jak UEFA, RADA, BAFTA i w przeciwieństwie do BBC, HTML, SSL
źródło
Istnieje również inna konwencja wielbłądów, która stara się poprawić czytelność akronimów za pomocą wielkich
HTML
lub małych liter (html
), ale unikając obu (Html
).Więc w twoim przypadku możesz pisać
getUNESCOProperties
. Możesz także napisaćunescoProperties
dla zmiennej lubUNESCOProperties
dla klasy (konwencja dla klas zaczyna się od wielkich liter).Ta reguła staje się trudna, jeśli chcesz połączyć dwa akronimy, na przykład dla klasy o nazwie Żądanie HTTP HTTP.
XMLHTTPRequest
Zaczynałby się od wielkich liter, ale ponieważ nie byłby łatwy do odczytania (czy jest to żądanie XMLH TTP?) IXMLhttpRequest
łamałby konwencję wielbłąda (czy to XM Lhttp Request?), Najlepszą opcją byłoby mieszanie wielkości liter:,XMLHttpRequest
która jest właściwie to, czego używał W3C . Jednak stosowanie tego rodzaju nazw jest odradzane. Dla tego przykładuHTTPRequest
lepsza nazwa.Ponieważ oficjalnym angielskim słowem identyfikacyjnym / identyfikacyjnym wydaje się być ID, chociaż nie jest akronimem, możesz zastosować tam te same reguły.
Ta konwencja wydaje się być dość popularna, ale to tylko konwencja i nie ma w niej dobra ani zła. Spróbuj trzymać się konwencji i upewnij się, że twoje imiona są czytelne.
źródło