Ho un dubbio su CamelCase. Supponi di avere questo acronimo:Unesco = United Nations Educational, Scientific and Cultural Organization.

Dovresti scrivere: unitedNationsEducationalScientificAndCulturalOrganization

E se fosse necessario scrivere l'acronimo? Qualcosa di simile a:

getUnescoProperties();

È giusto scriverlo in questo modo? getUnescoProperties() OR getUNESCOProperties();

Alcune linee guida su cui Microsoft ha scritto camelCasesono:

Quando si usano gli acronimi, usare il caso Pascal o il caso cammello per gli acronimi più lunghi di due caratteri. Ad esempio, utilizzare HtmlButtono htmlButton. Tuttavia, è necessario scrivere in maiuscolo acronimi composti da solo due caratteri, ad esempio System.IOanziché System.Io.

Non utilizzare abbreviazioni negli identificatori o nei nomi dei parametri. Se è necessario utilizzare abbreviazioni, utilizzare la custodia del cammello per abbreviazioni composte da più di due caratteri, anche se ciò contraddice l'abbreviazione standard della parola.

Riassumendo:

• Quando usi un'abbreviazione o un acronimo di due caratteri, mettili tutti in maiuscolo;

• Quando l'acronimo è più lungo di due caratteri, usa un capitale per il primo personaggio.

Quindi, nel tuo caso specifico, getUnescoProperties()è corretto.

Ci sono critiche legittime al consiglio Microsoft dalla risposta accettata.

• Trattamento incoerente di acronimi / inizialismi a seconda del numero di caratteri:
  • playerIDvs playerIdvs playerIdentifier.
• La domanda se gli acronimi a due lettere debbano comunque essere scritti in maiuscolo se compaiono all'inizio dell'identificatore:
  • USTaxes vs usTaxes
• Difficoltà nel distinguere più acronimi:
  • cioè USIDvs usId(o parseDBMXMLnell'esempio di Wikipedia).

Quindi pubblicherò questa risposta come alternativa alla risposta accettata. Tutti gli acronimi devono essere trattati in modo coerente; gli acronimi dovrebbero essere trattati come qualsiasi altra parola. Citando Wikipedia :

... alcuni programmatori preferiscono trattare le abbreviazioni come se fossero parole minuscole ...

Quindi ri: domanda di OP, sono d'accordo con la risposta accettata; questo è corretto:getUnescoProperties()

Ma penso che raggiungerei una conclusione diversa in questi esempi:

• US Taxes → usTaxes
• Player ID → playerId

Quindi vota per questa risposta se pensi che gli acronimi a due lettere debbano essere trattati come altri acronimi.

Camel Case è una convenzione, non una specifica. Quindi suppongo che le regole dell'opinione popolare.

( MODIFICA: eliminando questo suggerimento secondo cui i voti dovrebbero decidere la questione; come dice @Brian David; StackTranslate.it non è un "concorso di popolarità" e questa domanda è stata chiusa come "basata sull'opinione")

Anche se molti preferiscono trattare gli acronimi come qualsiasi altra parola, la pratica più comune potrebbe essere quella di mettere gli acronimi in maiuscolo (anche se porta a "abominazioni")

• Vedi "EDXML" in questo schema XML
• Vedi "SFAS158" in questo schema XBRL

Altre risorse:

• Nota che alcune persone distinguono tra abbreviazione e acronimi
• Nota Le linee guida Microsoft distinguono tra acronimi a due caratteri e "acronimi più lunghi di due caratteri"
• Nota che alcune persone raccomandano di evitare del tutto abbreviazioni / acronimi
• Nota alcune persone raccomandano di evitare del tutto CamelCase / PascalCase
• Nota alcune persone distinguono tra "coerenza" come "regole che sembrano internamente incoerenti" (cioè trattando acronimi a due caratteri diversi dagli acronimi a tre caratteri); alcune persone definiscono "coerenza" come "applicare la stessa regola in modo coerente" (anche se la regola è internamente incoerente)
• Linee guida per la progettazione del framework
• Linee guida Microsoft

In primo luogo, devo chiarire che non sono un madrelingua inglese , quindi la mia affermazione sulla grammatica inglese può semplicemente essere sbagliata. Se scopri tali errori, per favore fammi sapere, e sarò molto grato.

La migliore pratica per l'acronimo sarebbe evitare gli acronimi il più possibile. Comunque, questo non è il caso perché l'acronimo UNESCOè più familiare del nome completoUnitedNationsEducationalScientificAndCulturalOrganization .

Quindi, penso che UNESCOabbia più senso che Unescosemplicemente perché è più vicino alla forma di vita reale, quindi più familiare. Ho avuto qualche problema a capire quale fosse la parolaUnesco significhi effettivamente .

Come altro esempio, pensaci Arc. Sembra una curva attorno a un cerchio, ma in Rust significa questo Atomically Reference Counted. Se fosse stato scritto come ARC, almeno i lettori avrebbero riconosciuto che la parola è un acronimo di qualcos'altro piuttosto che una sorta di curva.

I programmi moderni sono scritti principalmente per i lettori umani. Quindi tali regole di denominazione devono essere impostate per la leggibilità umana piuttosto che per l'elaborazione o l'analisi della macchina.

In questa prospettiva, perdiamo un po 'di leggibilità usando Unescoover UNESCOsenza guadagnare nulla.

E per tutti gli altri casi, penso che seguire le semplici regole (o convenzioni) di acronimo inglese sia sufficiente per la maggior parte dei casi per una migliore leggibilità .

Per convertire in CamelCase, esiste anche l'algoritmo del caso Camel (quasi) deterministico di Google :

A partire dalla forma in prosa del nome:

1. Converti la frase in semplice ASCII e rimuovi eventuali apostrofi. Ad esempio, "l'algoritmo di Müller" potrebbe diventare "algoritmo di Mueller".
2. Dividi questo risultato in parole, dividendo gli spazi e l'eventuale punteggiatura rimanente (in genere trattini).
   1. Consigliato: se una parola ha già un aspetto convenzionale di una custodia di cammello di uso comune, suddividerla nelle sue parti costitutive (ad esempio, "AdWords" diventa "parole pubblicitarie"). Si noti che una parola come "iOS" non è in realtà in maiuscolo; sfida qualsiasi convenzione, quindi questa raccomandazione non si applica.
3. Ora minuscolo tutto (compresi gli acronimi), quindi maiuscolo solo il primo carattere di:
   1. ... ogni parola, per dare il caso di cammello superiore o
   2. ... ogni parola tranne la prima, per produrre una custodia di cammello inferiore
4. Infine, unisci tutte le parole in un unico identificatore.

Si noti che l'involucro delle parole originali è quasi del tutto ignorato.

Negli esempi seguenti, "Richiesta HTTP XML" viene correttamente trasformata in XmlHttpRequest, XMLHTTPRequest non è corretta.

getUnescoProperties() dovrebbe essere la soluzione migliore ...

Quando possibile, segui il puro camelCase, quando hai gli acronimi, lasciali maiuscoli quando possibile, altrimenti vai camelCase.

Generalmente in OO le variabili di programmazione dovrebbero iniziare con lettere minuscole ( lowerCamelCase) e la classe dovrebbe iniziare con lettere maiuscole ( UpperCamelCase).

In caso di dubbio, diventa puro camelCase;)

parseXMLva bene, lo parseXmlè anchecamelCase

XMLHTTPRequestdovrebbe essere XmlHttpRequesto xmlHttpRequestnon c'è modo di andare con i successivi acronimi maiuscoli, non è definitivamente chiaro per tutti i casi di test.

ad es. come leggi questa parola HTTPSSLRequest, HTTP + SSLo HTTPS + SL((ciò non significa altro che ...), in quel caso segui la convenzione sul caso dei cammelli e vai avanti httpSslRequesto httpsSlRequest, forse non è più bello, ma è sicuramente più chiaro.

C'è una guida di stile JavaScript di airbnb su github con molte stelle (~ 57.5k in questo momento) e guide sugli acronimi che dicono:

Acronimi e inizialismi devono sempre essere tutti in maiuscolo o in minuscolo.

Perché? I nomi sono per leggibilità, non per placare un algoritmo informatico.

// 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 = [
  // ...
];

Attualmente sto usando le seguenti regole:

1. Capitale caso per gli acronimi: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

2. Caso Camel per le abbreviazioni: ID[entifier], Exe[cutable], App[lication].

ID è un'eccezione, scusa ma vero.

Quando vedo una lettera maiuscola prendo un acronimo, cioè una parola separata per ogni lettera. Le abbreviazioni non hanno parole separate per ogni lettera, quindi uso il caso del cammello.

XMLHTTPRequest è ambiguo, ma è un caso raro e non è così ambiguo, quindi va bene, le regole e la logica sono più importanti della bellezza.

La guida di stile Airbnb di JavaScript ne parla un po ' . Fondamentalmente:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Poiché in genere leggo una lettera maiuscola come classe, tendo a evitarlo. Alla fine, è tutta una preferenza.

Oltre a ciò che ha detto @valex, voglio ricapitolare un paio di cose con le risposte fornite per questa domanda.

Penso che la risposta generale sia: dipende dal linguaggio di programmazione che stai usando.

C Sharp

Microsoft ha scritto alcune linee guida in cui sembra che HtmlButtonsia il modo giusto di nominare una classe per questi casi.

Javascript

Javascript ha alcune variabili globali con acronimi e le usa tutte in maiuscolo (ma stranamente, non sempre in modo coerente) ecco alcuni esempi:

encodeURIComponent XMLHttpRequest toJSON toISOString

disclaimer: l'inglese non è il tono di mia madre. Ma ho pensato a questo problema per molto tempo, specialmente quando si utilizza il nodo (stile camelcase) per gestire il database poiché il nome dei campi della tabella dovrebbe essere snakeizzato, questo è il mio pensiero:

Esistono 2 tipi di "acronimi" per un programmatore:

• in linguaggio naturale, UNESCO
• nel linguaggio di programmazione del computer, ad esempio tmc and textMessageContainer, che di solito appare come una variabile locale.

Nel mondo della programmazione, tutti gli acronimi in linguaggio naturale dovrebbero essere trattati come parole , i motivi sono:

1. quando programmiamo, dovremmo nominare una variabile in stile acronimo o non acronimo. Quindi, se chiamiamo una funzione getUNESCOProperties, significa che l'UNESCO è un acronimo (altrimenti non dovrebbe essere tutto in lettere maiuscole), ma evidentemente gete propertiesnon sono acronimi. quindi, dovremmo chiamare questa funzione come gunescop o getUnitedNationsEducationalScientificAndCulturalOrganizationProperties , entrambi sono inaccettabili.

2. il linguaggio naturale è in continua evoluzione e gli acronimi di oggi diventeranno parole domani , ma i programmi dovrebbero essere indipendenti da questa tendenza e rimanere per sempre.

a proposito, nella risposta più votata, IO è l'acronimo nel significato del linguaggio informatico (sta per InputOutput), ma non mi piace il nome, dal momento che penso che l'acronimo (nel linguaggio informatico) dovrebbe essere usato solo per nominare una variabile locale ma una classe / funzione di livello superiore, quindi InputOutput dovrebbe essere usato al posto di IO

L'UNESCO è un caso speciale in quanto di solito (in inglese) viene letto come una parola e non come un acronimo - come UEFA, RADA, BAFTA e diversamente da BBC, HTML, SSL

Esiste anche un'altra convenzione camelcase che cerca di favorire la leggibilità degli acronimi usando maiuscole ( HTML) o minuscole ( html), evitando entrambi ( Html).

Quindi nel tuo caso potresti scrivere getUNESCOProperties. Puoi anche scrivere unescoPropertiesper una variabile o UNESCOPropertiesper una classe (la convenzione per le classi deve iniziare con le maiuscole).

Questa regola diventa complicata se si desidera mettere insieme due acronimi, ad esempio per una classe denominata Richiesta HTTP XML. Inizierebbe con XMLHTTPRequestlettere maiuscole, ma dato che non sarebbe facile da leggere (è la richiesta XMLTP TTP?), E XMLhttpRequestinfrangerebbe la convenzione camelcase (è XM Lhttp Request?), L'opzione migliore sarebbe quella di mescolare case:, XMLHttpRequestche è in realtà ciò che il W3C ha usato . Tuttavia l'uso di questo tipo di denominazioni è scoraggiato. Per questo esempio, HTTPRequestsarebbe un nome migliore.

Poiché la parola inglese ufficiale per identificazione / identità sembra essere ID, anche se non è un acronimo, è possibile applicare le stesse regole lì.

Questa convenzione sembra essere abbastanza popolare là fuori, ma è solo una convenzione e non c'è giusto o sbagliato. Prova a rispettare una convenzione e assicurati che i tuoi nomi siano leggibili.