Acronymes dans CamelCase

Question

J'ai un doute sur CamelCase. Supposons que vous avez cet acronyme: Unesco = United Nations Educational, Scientific and Cultural Organization.

Vous devriez écrire: unitedNationsEducationalScientificAndCulturalOrganization

Mais si vous avez besoin d'écrire l'acronyme? Quelque chose comme:

getUnescoProperties();

Est-il juste de l'écrire de cette façon? getUnescoProperties() OR getUNESCOProperties();

Answer 1

Quelques guidelines Microsoft a écrit à propos de camelCase sont les suivants:

Lorsque vous utilisez des acronymes, utilisez des casses Pascal ou des chameaux pour les acronymes de plus de deux caractères. Par exemple, utilisez HtmlButton ou htmlButton. Toutefois, vous devez utiliser des acronymes composés de deux caractères seulement, tels que System.IO au lieu de System.Io.

N'utilisez pas d'abréviations dans les identificateurs ou les noms de paramètres. Si vous devez utiliser des abréviations, utilisez l'affaire chameau pour les abréviations comportant plus de deux caractères, même si cela contredit l'abréviation standard du mot.

En résumé:

• Lorsque vous utilisez une abréviation ou un acronyme de deux caractères, mettez-les en majuscules;

• Lorsque l'acronyme dépasse 2 caractères, utilisez une majuscule pour le premier caractère.

Donc, dans votre cas particulier, getUnescoProperties() est correct.

Answer 2

Il existe des critiques légitimes à l’égard du conseil Microsoft de la réponse acceptée. 

• Traitement incohérent des acronymes/initialismes en fonction du nombre de caractères:
  • playerID vs playerId vs playerIdentifier.
• La question de savoir si les acronymes à deux lettres doivent toujours être mis en majuscule s’ils apparaissent au début de l’identificateur:
  • USTaxes vs usTaxes
• Difficulté à distinguer plusieurs acronymes:
  • c'est-à-dire USID vs usId (ou parseDBMXML dans l'exemple de Wikipedia).

Je vais donc poster cette réponse comme une alternative à la réponse acceptée. Les votes peuvent décider. Tous les acronymes doivent être traités de manière cohérente. les acronymes doivent être traités comme n'importe quel autre mot. Citant Wikipedia :

... certains programmeurs préfèrent traiter les abréviations comme s'il s'agissait de minuscules ...

Donc, je re: la question de OP, je suis d'accord avec la réponse acceptée; c'est correct: getUnescoProperties()

Mais je pense que je parviendrais à une conclusion différente dans ces exemples:

• US Taxes → usTaxes
• Player ID → playerId

Alors votez pour cette réponse si vous pensez que les acronymes à deux lettres doivent être traités comme d'autres acronymes.

Camel Case est une convention, pas une spécification. Donc, je suppose que l'opinion populaire règne.

Et dans la recherche de la réponse "populaire" dans le code ou le balisage existant, la réponse acceptée peut-être bien.

• Voir "EDXML" dans ce Schéma XML
• Voir "SFAS158" dans ce schéma XBRL

Answer 3

Tout d’abord, je dois préciser que je ne parle pas anglais, donc ma thèse sur la grammaire anglaise peut être tout simplement fausse. Si vous découvrez de telles erreurs, s'il vous plaît faites le moi savoir, et je serai très reconnaissant.

---

La meilleure pratique pour les acronymes serait d’éviter autant que possible les acronymes ..__ De toute façon, ce n’est pas le cas car l’acronyme UNESCO est plus familier que le nom complet UnitedNationsEducationalScientificAndCulturalOrganization.

Ensuite, je pense que UNESCO a plus de sens que Unesco car il est tout simplement plus proche de la forme de la vie réelle, donc plus familier. J'ai eu du mal à comprendre ce que signifie Word Unesco.

Autre exemple, pensez à Arc. Cela ressemble à une courbe autour d’un cercle, mais dans Rust, cela signifie Atomically Reference Counted. Si c'est écrit comme suit ARC, au moins les lecteurs reconnaîtront que la Parole est un acronyme de quelque chose d'autre plutôt qu'une sorte de courbe.

Les programmes modernes sont écrits principalement pour des lecteurs humains. Ensuite, ces règles de nommage doivent être définies pour lisibilité humaine} _ plutôt que pour le traitement ou l'analyse sur ordinateur. 

Dans cette perspective, nous perdons un peu de lisibilité en utilisant Unesco sur UNESCO sans gagner rien.

Et pour tous les autres cas, je pense que le simple fait de suivre les règles simples (ou conventions) concernant les acronymes anglais suffit dans la plupart des cas pour meilleure lisibilité.

Answer 4

getUnescoProperties() devrait être la meilleure solution ...

Si possible, suivez simplement la pure camelCase, lorsque vous avez des acronymes, laissez-les simplement en majuscule si possible, sinon passez à camelCase.

Généralement, dans OO, les variables de programmation doivent commencer par une lettre minuscule (lowerCamelCase) et la classe par une lettre majuscule (UpperCamelCase).

En cas de doute, allez purement camelCase;)

parseXML va bien, parseXml est aussi camelCase

XMLHTTPRequest devrait être XmlHttpRequest ou xmlHttpRequest aucune voie à suivre avec les acronymes en majuscules ultérieurs, elle n’est définitivement pas claire pour tous les cas tests. 

par exemple, comment lisez-vous ce mot HTTPSSLRequest, HTTP + SSL ou HTTPS + SL (cela ne veut pas dire autre chose que ...), dans ce cas, respectez la convention relative aux cas de chameaux et optez pour httpSslRequest ou httpsSlRequest, ce n'est peut-être plus agréable, mais c'est nettement plus clair.

Answer 5

Pour convertir en CamelCase, il y a aussi l'algorithme de cas Camel (presque) déterministe de Camel :

Commençant par la forme de prose du nom:

1. Convertissez la phrase en plain ASCII et supprimez les apostrophes . Par exemple, "l'algorithme de Müller" pourrait devenir "algorithme de Muellers ".
2. Divisez ce résultat en mots, divisez en espaces et toute ponctuation restante (généralement des traits d'union). 
   1. Recommandé: si Word a déjà un étui de chameau conventionnel l’apparence courante, divisez-la en ses parties constitutives (Par exemple, "AdWords" devient "des mots publicitaires"). Notez qu'un mot tel comme "iOS" n'est pas vraiment dans l'affaire du chameau en soi; il défie tout convention, donc cette recommandation ne s'applique pas.
3. Maintenant tout en minuscule (y compris les acronymes), puis en majuscule seulement le premier caractère de: 
   1. … Chaque mot, pour donner supérieur cas de chameau, ou
   2. … Chaque mot, sauf le premier, à céder étui inférieur de chameau
4. Enfin, réunissez tous les mots dans un identifiant unique.

Notez que la casse des mots d'origine est presque entièrement ignoré.

Dans les exemples suivants, "Demande HTTP XML" est correctement transformé en XmlHttpRequest, XMLHTTPRequest est incorrect.

Answer 6

Il y a airbnb JavaScript Style Guide chez github avec beaucoup d’étoiles (~ 57,5k pour le moment) et des guides sur acronymes qui disent:

Les acronymes et les initialismes doivent toujours être tous en majuscules, ou tous minuscule.

Pourquoi? Les noms sont pour la lisibilité, pas pour apaiser un algorithme informatique.

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

Answer 7

J'utilise actuellement les règles suivantes:

1. Majuscule pour les acronymes: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

2. Affaire Camel pour les abréviations: ID[entifier], Exe[cutable], App[lication].

ID est une exception, désolé mais vrai.

Lorsque je vois une lettre majuscule, j’assume un acronyme, c’est-à-dire un mot distinct pour chaque lettre. Les abréviations n’ont pas des mots distincts pour chaque lettre, c’est pourquoi j’utilise casel.

XMLHTTPRequest est ambigu, mais c'est un cas rare et ce n'est pas si ambigu, alors c'est ok, les règles et la logique sont plus importantes que la beauté.

Answer 8

Le guide de style JavaScript Airbnb en parle un peu . Fondamentalement: 

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Comme je lis généralement une grande lettre majuscule en tant que classe, j'ai tendance à éviter cela. À la fin de la journée, tout est préférable. 

Answer 9

L’UNESCO est un cas particulier, car elle est généralement (en anglais) lue comme un mot et non comme un acronyme - comme UEFA, RADA, BAFTA et contrairement à la BBC, HTML, SSL

Answer 10

Il existe également une autre convention camelcase qui tente de favoriser la lisibilité des acronymes en utilisant soit des majuscules (HTML), soit des minuscules (html), mais en évitant les deux (Html).

Donc, dans votre cas, vous pourriez écrire getUNESCOProperties. Vous pouvez également écrire unescoProperties pour une variable ou UNESCOProperties pour une classe (la convention pour les classes est de commencer par majuscule).

Cette règle devient délicate si vous voulez assembler deux acronymes, par exemple pour une classe nommée XML HTTP Request. Cela commencerait par majuscule, mais comme XMLHTTPRequest ne serait pas facile à lire (XMLH TTP Request?), Et XMLhttpRequest enfreindrait la convention camelcase (s'agit-il de XM Lhttp Request?), La meilleure option serait de mélanger les cas: XMLHttpRequest , ce qui est en fait ce que le W3C a utilisé . Cependant, l'utilisation de ce type de noms est déconseillée. Pour cet exemple, HTTPRequest serait un meilleur nom.

Puisque le mot anglais officiel d'identification/identité semble être ID, bien qu'il ne s'agisse pas d'un acronyme, vous pouvez appliquer les mêmes règles.

Cette convention semble être très populaire, mais c'est juste une convention et il n'y a ni bon ni mauvais. Essayez simplement de vous en tenir à une convention et assurez-vous que vos noms sont lisibles. 

Answer 11

disclaimer: L'anglais n'est pas le ton de ma mère. Mais je réfléchis depuis longtemps à ce problème, en particulier lorsque vous utilisez node (style camelcase) pour gérer la base de données car le nom des champs de la table doit être transformé en un serpent, voici ce que je pense:

Il existe 2 types d’acronymes pour un programmeur:

• en langue naturelle, UNESCO
• dans le langage de programmation, par exemple, tmc and textMessageContainer, qui apparaît généralement sous forme de variable locale.

Dans le monde de la programmation, tous les acronymes en langage naturel doivent être traités comme Word, pour les raisons suivantes: 

1. lors de la programmation, nous devons nommer une variable de style acronyme ou non acronyme. Donc, si nous appelons une fonction getUNESCOProperties, cela signifie que l'UNESCO est un acronyme (sinon, il ne devrait pas s'agir de lettres majuscules), mais il est évident que get et properties ne sont pas des acronymes. donc, nous devrions nommer cette fonction soit gunescop soit getUnitedNationsEducationalScientificAndCulturalOrganizationProperties, les deux sont inacceptables.

2. le langage naturel évolue continuellement, et les acronymes d’aujourd’hui deviendront des mots de demain , mais les programmes doivent rester indépendants de cette tendance et rester éternels. 

à propos, dans la réponse la plus votée, IO est l'acronyme en langage informatique (signifie InputOutput), mais je n'aime pas le nom, car je pense que l'acronyme (en langage informatique) ne devrait être utilisé pour nommer une variable locale mais une classe/fonction de niveau supérieur, donc InputOutput doit être utilisé à la place de IO

Answer 12

En plus de ce que @valex a dit, je voudrais récapituler quelques points avec les réponses données à cette question.

Je pense que la réponse générale est: cela dépend du langage de programmation que vous utilisez.

C Sharp

Microsoft a écrit certaines directives dans lesquelles il semble que HtmlButton est la bonne façon de nommer une classe pour ce cas.

Javascript

Javascript comporte des variables globales avec des acronymes et les utilise tous en majuscules (mais curieusement, pas toujours de manière cohérente), voici quelques exemples:

encodeURIComponentXMLHttpRequesttoJSONtoISOString