Acronymes dans CamelCase [fermé]


243

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

Vous devez écrire: unitedNationsEducationalScientificAndCulturalOrganization

Mais que faire 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();


2
Cela ne devrait-il pas être sur programmers.SE?
Pacerier

5
La conversion de l'OMI en snake_case révèle la meilleure solution. Aimez-vous get_unesco_propertiesou get_u_n_e_s_c_o_properties?
jchook


Réponses:


195

Certaines lignes directrices sur lesquelles Microsoft a écrit camelCasesont:

Lorsque vous utilisez des acronymes, utilisez la casse Pascal ou la casse chameau pour les acronymes de plus de deux caractères. Par exemple, utilisez HtmlButtonou htmlButton. Cependant, vous devez mettre en majuscule les acronymes qui ne contiennent que deux caractères, comme au System.IOlieu 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 la casse de chameau pour les abréviations qui se composent de plus de deux caractères, même si cela contredit l'abréviation standard du mot.

Résumant:

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

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

Donc, dans votre cas spécifique, getUnescoProperties()c'est correct.


11
Je suppose que je devrais commencer à utiliser à la IDplace Id(que j'utilise / vois partout)
jasonscript

30
Techniquement, "ID" n'est pas un acronyme (c'est une abréviation d '"identifiant" ou "identification"), mais je ne sais pas vraiment comment / si cette directive aide avec celle-là. : - \
bryant

64
Je ne pense pas que ce soit un bon standard. La distinction des acronymes normaux, des acronymes à deux lettres et des mots normaux semble trop compliquée et contraire à l'idée d'avoir une convention de dénomination cohérente.
Sam

40
De plus, être déclaré par Microsoft ne fait pas quelque chose de "correct".
Sam

48
C'est agréable de savoir qu'ils suivent leur propre ligne directrice: XMLHttpRequest()originaire de Microsoft.
Makyen

315

Il y a des critiques légitimes des conseils de Microsoft à partir de la réponse acceptée.

  • Traitement incohérent des acronymes / initialismes selon le nombre de caractères:
    • playerIDvs playerIdvs playerIdentifier.
  • La question de savoir si les acronymes à deux lettres doivent toujours être en majuscule s'ils apparaissent au début de l'identifiant:
    • USTaxes contre usTaxes
  • Difficulté à distinguer plusieurs acronymes:
    • c'est-à-dire USIDvs usId(ou parseDBMXMLdans l'exemple de Wikipedia).

Je vais donc publier cette réponse comme alternative à la réponse acceptée. Tous les acronymes doivent être traités de manière cohérente; les acronymes doivent être traités comme tout autre mot. Citant Wikipédia :

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

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

Mais je pense que j'arriverais à une conclusion différente dans ces exemples:

  • US TaxesusTaxes
  • Player IDplayerId

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

Camel Case est une convention, pas une spécification. Je suppose donc que les règles d'opinion populaire.

( EDIT: Suppression de cette suggestion selon laquelle les votes devraient décider de cette question; comme @Brian David le dit; Stack Overflow n'est pas un "concours de popularité", et cette question a été fermée comme "basée sur l'opinion")

Même si beaucoup préfèrent traiter les acronymes comme n'importe quel autre mot, la pratique la plus courante peut être de mettre des acronymes en majuscules (même si cela conduit à des "abominations")

Autres ressources:

  • Notez que certaines personnes font la distinction entre l'abréviation et les acronymes
  • Remarque Les directives Microsoft distinguent les acronymes à deux caractères des «acronymes de plus de deux caractères»
  • Notez que certaines personnes recommandent d'éviter complètement les abréviations / acronymes
  • Notez que certaines personnes recommandent d'éviter CamelCase / PascalCase complètement
  • Notez que certaines personnes distinguent la «cohérence» comme des «règles qui semblent incohérentes en interne» (c'est-à-dire en traitant les acronymes à deux caractères différents des acronymes à trois caractères); certaines personnes définissent la «cohérence» comme «l'application constante de la même règle» (même si la règle est incohérente en interne)
  • Lignes directrices sur la conception du cadre
  • Consignes Microsoft

26
1) Il n'y a pas d'incohérence. "Id" est une abréviation , pas un acronyme. 2) Cela dépend du contexte de l'identifiant, c'est-à-dire de la classe, de l'interface, de l'attribut, du type d'énumération, du champ statique, du paramètre, de la méthode, de la propriété ou de l'événement. Si la directive pour l'identifiant utilise PascalCase, alors ce serait USTaxeset PlayerId; camelCase: usTaxeset playerId. 3) Ce serait USIden PascalCase, usIden camelCase et parseDbmXmlen camelCase.
Frederik Krautwald

6
Tu as raison, c'est une abréviation. Mon point est que ce devrait être UsTaxes, UsId. Les «abréviations ou acronymes» à deux lettres ne doivent pas être traités différemment des trois lettres ou autres «mots normaux». Un autre conseil, de la réponse de @ Eonil, est d'éviter complètement les raccourcisseurs. unitedStatesTaxes ou playerIdentifier.
The Red Pea

3
Ha ha. Je doute que la confusion se produise - beaucoup - mais les lignes directrices sont, bien, des lignes directrices pour éviter une éventuelle confusion. Un exemple acronyme artificiel (mauvais) dans un contexte scientifique: InIN(item)vs InIn(item)(indice: IN est pouces (es)). Ou, IDById(id)vs IdById(id), science du contexte (indice: ID signifie maladie infectieuse). "Deux caractères de long" - dans quel contexte?
Frederik Krautwald,

2
Sur le lien Microsoft "... utilisez le cas Pascal ou le cas chameau pour les acronymes de plus de deux caractères . ... Cependant, vous devez mettre en majuscule les acronymes qui ne contiennent que deux caractères ..." C'est la partie que j'appellerais "incohérente". ". Une meilleure caractérisation est une "exception". Et au moins vous avez rationalisé pourquoi les acronymes à deux lettres pourraient être plus confus. Mais je suppose que ces programmes avec "CanCan" n'ont pas de chance; ambigu que ce soit le dance-move, ou le réseau communautaire du Cercle de l'Aviron de Nantes :)
The Red Pea

18
L'auteur de Capital Offense: Comment gérer les abréviations dans CamelCase invoque correctement le terme "abomination" lorsqu'il écrit: "Bien que [l'utilisation d'acronymes majuscules] fonctionne dans des cas simples, cela conduit à des abominations lorsqu'une abréviation se succède: HTTPURLConnection, XMLIDREF"
kghastie

21

Tout d'abord, je dois préciser que je ne suis pas un anglophone natif , donc mon affirmation sur la grammaire anglaise peut tout simplement être erronée. Si vous découvrez de telles erreurs, faites-le moi savoir et je vous en serai très reconnaissant.


La meilleure pratique pour l'acronyme serait d'éviter autant que possible les acronymes. Quoi qu'il en soit, ce n'est pas le cas car l'acronyme UNESCOest plus familier que le nom completUnitedNationsEducationalScientificAndCulturalOrganization .

Ensuite, je pense que UNESCOc'est plus logique queUnesco parce que c'est tout simplement plus proche de la forme de vie réelle, donc plus familier. J'ai eu du mal à comprendre ce que le motUnesco signifie réellement.

Comme autre exemple, réfléchissez Arc. Cela ressemble à une courbe autour d'un cercle, mais dans Rust, cela signifieAtomically Reference Counted . Si c'est écrit commeARC , au moins les lecteurs reconnaîtraient que le mot est un acronyme d'autre chose plutôt qu'une sorte de courbe.

Les programmes modernes sont écrits principalement pour les lecteurs humains. Ensuite, ces règles de dénomination doivent être définies pour une lisibilité humaine plutôt que pour le traitement ou l'analyse de la machine.

Dans cette perspective, nous perdons une certaine lisibilité en utilisant UnescoplusUNESCO sans gagner rien.

Et pour tous les autres cas, je pense que le simple fait de suivre les règles (ou conventions) de l'acronyme anglais est suffisant pour la plupart des cas pour une meilleure lisibilité .


4
Les exemples ci-dessus sont un peu trompeurs. "La meilleure approche que j'ai jamais vue était celle d'Apple ... Cela signifie traiter les acronymes comme un nom propre ... L'UNESCO a donc plus de sens" - Ce n'est pas ainsi que vous écrivez des noms propres.
Mikko Rantanen

@MikkoRantanen J'ai mis à jour ma réponse.
Eonil

7
Wow, je peux à peine trouver une phrase dans cette réponse avec laquelle je serais d'accord :-)
Josef Sábl

Cela dépend complètement du contexte du code sur lequel vous travaillez, que les abréviations / acronymes aient plus ou moins de sens. Par exemple, je travaille dans la finance, et il y a tellement de termes uniques qui sont uniformes dans l'industrie et en fait dans le monde entier. Vous perdriez du temps et créeriez une verbosité inutile en n'utilisant pas d'acronymes que tous ceux qui travailleront dans cette entreprise connaissent par cœur. Par exemple PV pour la valeur actuelle, FV pour la valeur future, moy pour la moyenne, exp pour l'exposant, etc.
Will Ediger

@ pm100 N'est-ce pas ce que j'ai dit? L'UNESCO n'est pas la façon dont vous écrivez les noms propres.
Mikko Rantanen

17

Pour convertir en CamelCase, il existe également l'algorithme de cas de Camel (presque) déterministe de Google :

Commençant par la forme en prose du nom:

  1. Convertissez la phrase en ASCII ordinaire et supprimez toutes les apostrophes. Par exemple, "l'algorithme de Müller" pourrait devenir "l'algorithme de Muellers".
  2. Divisez ce résultat en mots, en divisant les espaces et toute ponctuation restante (généralement des tirets).
    1. Recommandé: si un mot a déjà une apparence de boîtier de chameau conventionnelle dans l'usage courant, divisez-le en ses parties constitutives (par exemple, "AdWords" devient "mots d'annonce"). Notez qu'un mot tel que "iOS" n'est pas vraiment dans le cas de chameau en soi; il défie toute convention, donc cette recommandation ne s'applique pas.
  3. Maintenant tout en minuscules (y compris les acronymes), puis en majuscules uniquement le premier caractère de:
    1. … À chaque mot, pour donner la casière supérieure du chameau, ou
    2. … Chaque mot sauf le premier, pour donner une caisse de chameau inférieure
  4. Enfin, joignez tous les mots en un seul identifiant.

Notez que la casse des mots originaux est presque entièrement ignorée.

Dans les exemples suivants, la «demande HTTP XML» est correctement transformée en XmlHttpRequest, XMLHTTPRequest est incorrect.


17

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

Lorsque cela est possible, suivez simplement le pur camelCase, lorsque vous avez des acronymes, laissez-les en majuscules lorsque cela est possible, sinon camelCase.

En général, dans la programmation OO, les variables doivent commencer par une lettre minuscule ( lowerCamelCase) et la classe doit commencer par une lettre majuscule (UpperCamelCase ).

En cas de doute, devenez pur camelCase;)

parseXMLc'est bien, parseXmlc'est aussicamelCase

XMLHTTPRequestdevrait être XmlHttpRequestou xmlHttpRequestpas possible d'aller avec les acronymes suivants en majuscules, ce n'est définitivement pas clair pour tous les cas de test.

par exemple, comment lisez-vous ce mot HTTPSSLRequest , HTTP + SSLou HTTPS + SL(cela ne signifie rien , mais ...), dans ce cas , suivi de la convention de cas de chameau et aller pour httpSslRequestou httpsSlRequest, il est peut - être plus agréable, mais il est certainement plus clair.


2
J'aime votre HTTPSSLexemple, bien que SL ne signifie rien, que diriez-vous de quelque chose comme HTTPSSHTunnel? Est-ce HTTPS + SH (shell) ou HTTP + SSH? La convention de Google est nettement moins ambiguë.
L. Holanda

10

Il y a un guide de style JavaScript airbnb sur github avec beaucoup d'étoiles (~ 57,5 ​​k en ce moment) et des guides sur les acronymes qui disent:

Les acronymes et les initialismes doivent toujours être en majuscules ou en minuscules.

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

7
" Pourquoi? Les noms sont pour la lisibilité, pas pour apaiser un algorithme informatique " donc, XMLHTTPRequestest bien mieux lisible que XmlHttpRequest, non?
L. Holanda du

2
Cela n'a pas de sens pourquoi httpRequestsest considéré comme bon mais HttpRequestsmauvais. suivant ce principe, pour XML HTTP Request devrait être xmlhttpRequest???
L. Holanda du

1
Je cite souvent le guide de style AirBnb, mais dans ce cas, je ne suis pas d'accord. Je ne suis pas particulièrement d'accord avec leur affirmation: "Les acronymes et les initialismes devraient toujours être tous en majuscules ou en minuscules.". xmlHttpRequestest plus lisible qu'à XMLHTTPRequestmon avis.
Ronan

3

Actuellement, j'utilise les règles suivantes:

  1. Cas de la capitale pour les acronymes: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

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

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

Lorsque je vois une majuscule, j'assume un acronyme, c'est-à-dire un mot distinct pour chaque lettre. Les abréviations n'ont pas de mots séparés pour chaque lettre, donc j'utilise le cas de chameau.

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


1

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

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Parce que je lis généralement une lettre majuscule en classe, j'ai tendance à éviter cela. À la fin de la journée, c'est toute préférence.


1

En plus de ce que @valex a dit, je veux récapituler quelques éléments 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 quelques directives où il semble que ce HtmlButtonsoit la bonne façon de nommer une classe pour ces cas.

Javascript

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

encodeURIComponent XMLHttpRequest toJSON toISOString


Eh bien, c'est Netscape vieux, il en a même sans camelCase onerror.
Eddie

1

Avertissement: L'anglais n'est pas mon ton de mère. Mais j'ai pensé à ce problème depuis longtemps, en particulier lors de l'utilisation de noeud (style camelcase) pour gérer la base de données car le nom des champs de table doit être serpenté, voici ma pensée:

Il existe 2 types d'acronymes pour un programmeur:

  • en langage naturel, UNESCO
  • dans le langage de programmation informatique, par exemple tmc and textMessageContainer, qui apparaît généralement comme une variable locale.

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

  1. lorsque nous programmons, nous devons nommer une variable soit en style acronyme soit en style non acronyme. Donc, si nous nommons une fonction getUNESCOProperties, cela signifie que l'UNESCO est un acronyme (sinon ce ne devrait pas être toutes des lettres majuscules), mais évidemment, getet ce propertiesne sont pas des acronymes. nous devons donc nommer cette fonction gunescop ou getUnitedNationsEducationalScientificAndCulturalOrganizationProperties , les deux sont inacceptables.

  2. le langage naturel évolue continuellement, et les acronymes d'aujourd'hui deviendront des mots pour demain , mais les programmes devraient être indépendants de cette tendance et durer éternellement.

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


"langue", pas "ton"
Dan Dascalescu

0

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


1
C'est la distinction entre "acronymes" et simples "abréviations"; cette distinction semble pertinente pour l'ensemble du débat, mais a été presque entièrement élucidée dans les réponses présentées.
simon

BBC, HTML, SSL et autres acronymes où vous entendez chaque lettre sont plus précisément appelés initialismes. Des mots comme l'UNESCO qui se prononcent comme un mot sont de vrais acronymes.
Lrdwhyt

-2

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 unescoPropertiespour une variable ou UNESCOPropertiespour une classe (la convention pour les classes est de commencer par des majuscules).

Cette règle devient délicate si vous souhaitez regrouper deux acronymes, par exemple pour une classe nommée XML HTTP Request. Cela commencerait par des majuscules, mais comme XMLHTTPRequestil ne serait pas facile à lire (est-ce une demande TTP XMLH?), Et XMLhttpRequestbriserait la convention de camelcase (est-ce une demande LHttp XM?), La meilleure option serait de mélanger la casse:, XMLHttpRequestqui est en fait ce que le W3C a utilisé . Cependant, l'utilisation de ce type de dénominations est déconseillée. Pour cet exemple, HTTPRequestserait un meilleur nom.

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

Cette convention semble être assez populaire là-bas, mais c'est juste une convention et il n'y a pas de bien ou de mal. Essayez simplement de vous en tenir à une convention et assurez-vous que vos noms sont lisibles.


3
Je ne crois pas tout ce fil :-) Donc ce serait XMLToHtmlConverter mais HTMLToXmlConverter? Wow ...
Josef Sábl

1
@ JosefSábl, oui, ce serait comme ça. Concernant votre downvote, je ne dis pas que j'aime cette convention, mais elle existe définitivement.
Jesús Carrera

1
J'ai lu la question comme "Quelle est la bonne convention d'écriture des accronymes en cas de chameau" et non "Pouvez-vous lister toutes les conventions qui existent". Et comme je considère votre convention mentionnée comme très mauvaise, j'ai rétrogradé :-)
Josef Sábl

Eh bien, la question est "Est-il juste de l'écrire de cette façon?", Et comme il existe de nombreuses "bonnes" façons de l'écrire parce que c'est juste une convention, et cette convention est assez populaire la réponse est très valable :-)
Jesús Carrera
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.