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();

Niektóre wytyczne , o których pisał Microsoft, camelCaseto:

Używając akronimów, używaj wielkości Pascal lub wielbłąda w przypadku skrótów dłuższych niż dwa znaki. Na przykład użyj HtmlButtonlub htmlButton. Należy jednak używać wielkich liter, które składają się tylko z dwóch znaków, takich jak System.IOzamiast System.Io.

Nie używaj skrótów w identyfikatorach lub nazwach parametrów. Jeśli musisz używać skrótów, używaj wielbłąda dla skrótów, które składają się z więcej niż dwóch znaków, nawet jeśli jest to sprzeczne ze standardowym skrótem tego słowa.

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.

Istnieje uzasadniona krytyka porady Microsoft z zaakceptowanej odpowiedzi.

• Niespójne traktowanie akronimów / inicjalizacji w zależności od liczby znaków:
  • playerIDvs playerIdvs playerIdentifier.
• Pytanie, czy dwuliterowe akronimy powinny być nadal pisane wielkimi literami, jeśli pojawiają się na początku identyfikatora:
  • USTaxes vs usTaxes
• Trudność w rozróżnieniu wielu akronimów:
  • tj. USIDvs usId(lub parseDBMXMLw 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ę :

... niektórzy programiści wolą traktować skróty tak, jakby były małymi słowami ...

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

• Zobacz „EDXML” w tym schemacie XML
• Zobacz „SFAS158” w tym schemacie XBRL

Inne zasoby:

• Zauważ, że niektóre osoby rozróżniają skrót od akronimów
• Uwaga Wytyczne Microsoft rozróżniają akronimy dwuznakowe od „akronimów dłuższych niż dwa znaki”
• Uwaga: niektórzy ludzie zalecają unikanie skrótów / akronimów
• Uwaga: niektóre osoby zalecają całkowite unikanie CamelCase / PascalCase
• Zauważ, że niektórzy ludzie rozróżniają „spójność” jako „reguły, które wydają się wewnętrznie niespójne” (tzn. Traktują dwuznakowe akronimy inne niż trzyznakowe akronimy); niektóre osoby definiują „spójność” jako „konsekwentne stosowanie tej samej reguły” (nawet jeśli reguła jest wewnętrznie niespójna)
• Wytyczne dotyczące projektowania ram
• Wytyczne Microsoft

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 UNESCOjest bardziej znany niż pełna nazwa UnitedNationsEducationalScientificAndCulturalOrganization.

Zatem myślę, że UNESCOma 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 tak Unesconaprawdę oznacza to słowo .

Jako kolejny przykład zastanów się Arc. To brzmi jak zakręt wokół koła, ale w Rust oznacza to Atomically Reference Counted. Gdyby zostało napisane w ten sposób ARC, 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 Unescoponad UNESCOzyskują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 .

Aby przekonwertować na CamelCase, istnieje również (prawie) deterministyczny algorytm wielbłąda Google'a :

Począwszy od formy prozerskiej imienia:

1. Konwertuj frazę na zwykły ASCII i usuń wszelkie apostrofy. Na przykład „algorytm Müllera” może stać się „algorytmem Muellera”.
2. Podziel ten wynik na słowa, rozdzielając spacje i wszelkie pozostałe znaki interpunkcyjne (zwykle łączniki).
   1. Zalecane: jeśli dowolne słowo ma już powszechnie używany wygląd wielbłąda, podziel je na części składowe (np. „AdWords” staje się „słowami reklam”). Zauważ, że słowo takie jak „iOS” nie jest tak naprawdę w przypadku wielbłądów per se; sprzeciwia się jakiejkolwiek konwencji, więc to zalecenie nie ma zastosowania.
3. Teraz wszystko małymi literami (łącznie z akronimami), a następnie tylko pierwsza litera:
   1. … Każde słowo, aby uzyskać górną literę wielbłąda, lub
   2. … Każde słowo oprócz pierwszego, w celu uzyskania niższej wielkości wielbłąda
4. Na koniec połącz wszystkie słowa w jeden identyfikator.

Pamiętaj, że obudowa oryginalnych słów jest prawie całkowicie pomijana.

W poniższych przykładach „Żądanie HTTP HTTP” zostało poprawnie przekształcone na XmlHttpRequest, XMLHTTPRequest jest niepoprawny.

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 razie camelCase.

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

parseXMLjest w porządku, parseXmlteżcamelCase

XMLHTTPRequestpowinny być XmlHttpRequestlub xmlHttpRequestnie 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 + SSLalbo HTTPS + SL(to nic nie znaczy, ale ...), w tym przypadku obserwacji camel sprawa konwencji i pójść na httpSslRequestlub httpsSlRequest, być może nie ma już ładne, ale jest zdecydowanie bardziej wyraźne.

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ą:

Akronimy i inicjały powinny zawsze być pisane wielkimi literami lub małymi literami.

Czemu? Nazwy mają na celu czytelność, a nie uspokojenie algorytmu komputerowego.

// bad
import SmsContainer from './containers/SmsContainer';

// bad
const HttpRequests = [
  // ...
];

// good
import SMSContainer from './containers/SMSContainer';

// good
const HTTPRequests = [
  // ...
];

// also good
const httpRequests = [
  // ...
];

// best
import TextMessageContainer from './containers/TextMessageContainer';

// best
const requests = [
  // ...
];

Obecnie korzystam z następujących zasad:

1. Sprawa kapitał dla akronimów: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

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

Przewodnik po stylu JavaScript Airbnb mówi o tym trochę . Gruntownie:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Ponieważ zwykle czytam wielką literę jako klasę, zwykle tego unikam. Na koniec dnia wszystko jest preferencyjne.

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 HtmlButtonjest 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

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:

• w języku naturalnym, UNESCO
• na przykład w języku programowania komputerowego 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:

1. 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, geti propertiesnie są akronimy. dlatego powinniśmy nazwać tę funkcję albo gunescop, albo getUnitedNationsEducationalScientificAndCulturalOrganizationProperties , oba są niedopuszczalne.

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

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

Istnieje również inna konwencja wielbłądów, która stara się poprawić czytelność akronimów za pomocą wielkich HTMLlub małych liter ( html), ale unikając obu ( Html).

Więc w twoim przypadku możesz pisać getUNESCOProperties. Możesz także napisać unescoPropertiesdla zmiennej lub UNESCOPropertiesdla 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. XMLHTTPRequestZaczynałby się od wielkich liter, ale ponieważ nie byłby łatwy do odczytania (czy jest to żądanie XMLH TTP?) I XMLhttpRequestłamałby konwencję wielbłąda (czy to XM Lhttp Request?), Najlepszą opcją byłoby mieszanie wielkości liter:, XMLHttpRequestktóra jest właściwie to, czego używał W3C . Jednak stosowanie tego rodzaju nazw jest odradzane. Dla tego przykładu HTTPRequestlepsza 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.