Akronimy w CamelCase [zamknięte]

243

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

gal007
źródło
2
Czy nie powinno to być na programmers.SE?
Pacerier
5
Konwersja IMO do snake_case ujawnia najlepsze rozwiązanie. Lubisz get_unesco_propertieslub get_u_n_e_s_c_o_properties?
jchook
Powiązane pytanie: stackoverflow.com/questions/4504508/camel-casing-acronyms
Anton Tarasenko

Odpowiedzi:

195

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.

OPROGRAMOWANIE Apollo
źródło
11
Myślę, że powinienem zacząć IDzamiast tego Id(którego używam / widzę wszędzie)
jasonscript
30
Technicznie „ID” nie jest akronimem (jest skrótem od „identyfikatora” lub „identyfikacji”), ale tak naprawdę nie wiem, jak / jeśli ta wytyczna pomaga w tym. : - \
bryant
64
Nie sądzę, żeby to był dobry standard. Rozróżnianie normalnych akronimów, dwuliterowych akronimów i zwykłych słów wydaje się nadmiernie skomplikowane i sprzeczne z ideą posiadania spójnej konwencji nazewnictwa.
Sam
40
Ponadto stwierdzenie przez Microsoft nie czyni czegoś „poprawnym”.
Sam
48
Miło wiedzieć, że kierują się własnymi wytycznymi: XMLHttpRequest()pierwotnie pochodzą od Microsoft.
Makyen,
315

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 TaxesusTaxes
  • Player IDplayerId

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:

  • 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
The Red Pea
źródło
26
1) Nie ma niespójności. „Id” to skrót , a nie akronim. 2) Zależy to od kontekstu identyfikatora, tj. Klasy, interfejsu, atrybutu, typu wyliczenia, pola statycznego, parametru, metody, właściwości lub zdarzenia. Jeśli wytyczna dla identyfikatora używa PascalCase, to byłoby USTaxesi PlayerId; camelCase: usTaxesi playerId. 3) Będzie to USIdw PascalCase, usIdw camelCase i parseDbmXmlw camelCase.
Frederik Krautwald
6
Masz rację, to skrót. Chodzi mi o to, że powinien to być UsTaxes, UsId. Dwuliterowy „skrót lub akronim” nie powinien być traktowany inaczej niż trzyliterowe lub inne „normalne słowa”. Inną radą, z odpowiedzi @ Eonil, jest całkowite unikanie skracaczy. unitedStatesTaxes lub playerIdentifier.
The Red Pea
3
Ha ha. Wątpię, by powstało zamieszanie - wiele - ale wytyczne są, no cóż, wytycznymi, aby zapobiec możliwemu zamieszaniu. Przemyślany (zły) akronim w kontekście naukowym: InIN(item)vs InIn(item)(wskazówka: IN to cal (y)). Lub IDById(id)kontra IdById(id)nauka kontekstowa (wskazówka: ID oznacza chorobę zakaźną). „Dwa znaki długie” - w jakim kontekście?
Frederik Krautwald
2
W linku Microsoft „... używaj skrzynki Pascala lub skrzynki wielbłąda dla akronimów o długości większej niż dwa znaki . ... Powinieneś jednak używać akronimów składających się tylko z dwóch znaków ...” To jest część, którą nazwałbym „niekonsekwentną” „. Lepsza charakterystyka to „wyjątek”. Przynajmniej zracjonalizowałeś, dlaczego dwa akronimy literowe mogą być bardziej pomieszane. Ale myślę, że te programy z „CanCan” po prostu nie mają szczęścia; niejednoznaczne, czy to ruch taneczny, czy sieć społecznościowa Cercle de l'Aviron de Nantes :)
The Red Pea
18
Autor Capital Offense: Jak obchodzić się ze skrótami w CamelCase poprawnie przywołuje termin „obrzydliwość”, gdy pisze: „Chociaż [używanie akronimów wielkich liter] działa w prostych przypadkach, prowadzi do obrzydliwości, gdy jeden skrót następuje po drugim: HTTPURLConnection, XMLIDREF”
kghastie
21

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 .

Eonil
źródło
4
Powyższe przykłady są nieco mylące. „Najlepsze podejście, jakie kiedykolwiek widziałem, to Apple… To oznacza traktowanie akronimów jak właściwego rzeczownika… Więc UNESCO ma więcej sensu” - nie tak piszesz właściwe rzeczowniki.
Mikko Rantanen
@MikkoRantanen Zaktualizowałem swoją odpowiedź.
Eonil
7
Wow, trudno znaleźć w tej odpowiedzi zdanie, z którym bym się zgodził :-)
Josef Sábl
Zależy to całkowicie od kontekstu kodu, nad którym pracujesz, czy skróty / akronimy mają mniej lub bardziej sens. Na przykład pracuję w dziale finansów i istnieje wiele unikalnych terminów, które są jednolite w całej branży, a właściwie na całym świecie. Tracilibyście czas i tworzyliście niepotrzebną gadatliwość, nie używając akronimów, które wszyscy, którzy będą pracować w tej firmie, znają na pamięć. Np. PV dla wartości bieżącej, FV dla wartości przyszłej, śr. Dla średniej, exp dla wykładnika itp.
Czy Ediger
@ pm100 Czy to nie to, co powiedziałem? UNESCO nie jest tym, jak piszesz właściwe rzeczowniki.
Mikko Rantanen,
17

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.

serv-inc
źródło
17

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.

luk_z
źródło
2
Podoba mi się twój HTTPSSLprzykł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.
L. Holanda,
10

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 = [
  // ...
];
valex
źródło
7
Dlaczego? Nazwy mają na celu czytelność, a nie uspokojenie algorytmu komputerowego ”, więc czy XMLHTTPRequestjest o wiele lepiej czytelny niż XmlHttpRequest, prawda?
L. Holanda,
2
Nie ma sensu, dlaczego httpRequestsjest uważany za dobry, ale HttpRequestszły. zgodnie z tą zasadą, dla żądania HTTP HTTP powinno być xmlhttpRequest???
L. Holanda,
1
Często cytuję przewodnik po stylu AirBnb, ale w tym przypadku nie zgadzam się. W szczególności nie zgadzam się z ich stwierdzeniem: „Akronimy i inicjały powinny zawsze być pisane wielkimi lub małymi literami”. xmlHttpRequestjest bardziej czytelny niż XMLHTTPRequestmoim zdaniem.
Ronan
3

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.

użytkownik2992258
źródło
1

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.

Bryantee
źródło
1

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

Lante
źródło
Cóż, jest stary Netscape, ma nawet kilka bez camelCase onerror.
Eddie,
1

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

xiechao06
źródło
„język”, a nie „ton”
Dan Dascalescu
0

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

użytkownik1833431
źródło
1
Jest to różnica między „akronimami” a zwykłymi „skrótami”; rozróżnienie to wydaje się mieć znaczenie dla całej dyskusji, ale zostało prawie całkowicie pominięte w przedstawionych odpowiedziach.
simon
BBC, HTML, SSL i inne akronimy, w których wypowiadasz każdą literę, są dokładniej nazywane inicjalizacjami. Słowa takie jak UNESCO wymawiane jako słowo to prawdziwe akronimy.
Lrdwhyt
-2

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.

Jesús Carrera
źródło
3
Nie wierzę w ten cały wątek :-) Więc byłby to XMLToHtmlConverter, ale HTMLToXmlConverter? Wow ...
Josef Sábl,
1
@ JosefSábl, tak, tak by było. Jeśli chodzi o twoje zdanie, nie mówię, że podoba mi się ta konwencja, ale na pewno istnieje.
Jesús Carrera
1
Przeczytałem pytanie jako „Jaka jest dobra konwencja pisania akronimów w przypadku wielbłądów”, a nie „Czy można wymienić wszystkie istniejące konwencje”. A ponieważ uważam pańską wspomnianą konwencję za bardzo złą, zrewidowałem :-)
Josef Sábl
Pytanie brzmi: „Czy można tak pisać w ten sposób?”, A ponieważ istnieje wiele „właściwych” sposobów pisania, ponieważ jest to tylko konwencja, a ta konwencja jest dość popularna (niezależnie od tego, jak ją postrzegasz), mój odpowiedź jest bardzo ważna :-)
Jesús Carrera