355

I have a doubt about CamelCase. Suppose you have this acronym: Unesco = United Nations Educational, Scientific and Cultural Organization.

You should write: unitedNationsEducationalScientificAndCulturalOrganization

But what if you need to write the acronym? Something like:

getUnescoProperties();

Is it right to write it this way? getUnescoProperties() OR getUNESCOProperties();

M. Justin
  • 14,487
  • 7
  • 91
  • 130
gal007
  • 6,911
  • 8
  • 47
  • 70
  • 30
    IMO converting to snake_case reveals the best solution. Do you like `get_unesco_properties` or `get_u_n_e_s_c_o_properties`? – jchook Apr 05 '18 at 18:41
  • 1
    Related post - [Should the variable be named Id or ID?](https://softwareengineering.stackexchange.com/q/186277/236257) – RBT Aug 06 '19 at 10:18
  • Related question: https://stackoverflow.com/questions/4504508/camel-casing-acronyms – Anton Tarasenko May 21 '20 at 13:42

11 Answers11

412

There are legitimate criticisms of the Microsoft advice from the accepted answer.

  • Inconsistent treatment of acronyms/initialisms depending on number of characters:
  • playerID vs playerId vs playerIdentifier.
  • The question of whether two-letter acronyms should still be capitalized if they appear at the start of the identifier:
  • USTaxes vs usTaxes
  • Difficulty in distinguishing multiple acronyms:
  • i.e. USID vs usId (or parseDBMXML in Wikipedia's example).

So I'll post this answer as an alternative to accepted answer. All acronyms should be treated consistently; acronyms should be treated like any other word. Quoting Wikipedia:

...some programmers prefer to treat abbreviations as if they were lower case words...

So re: OP's question, I agree with accepted answer; this is correct: getUnescoProperties()

But I think I'd reach a different conclusion in these examples:

  • US TaxesusTaxes
  • Player IDplayerId

So vote for this answer if you think two-letter acronyms should be treated like other acronyms.

Camel Case is a convention, not a specification. So I guess popular opinion rules.

( EDIT: Removing this suggestion that votes should decide this issue; as @Brian David says; Stack Overflow is not a "popularity contest", and this question was closed as "opinion based")

Even though many prefer to treat acronyms like any-other word, the more common practice may be to put acronyms in all-caps (even though it leads to "abominations")

Other Resources:

  • Note some people distinguish between abbreviation and acronyms
  • Note Microsoft guidelines distinguish between two-character acronyms, and "acronyms more than two characters long"
  • Note some people recommend to avoid abbreviations / acronyms altogether
  • Note some people recommend to avoid camelCase / PascalCase altogether
  • Note some people distinguish between "consistency" as "rules that seem internally inconsistent" (i.e. treating two-character acronyms different than three-character acronyms); some people define "consistency" as "applying the same rule consistently" (even if the rule is internally inconsistent)
  • Framework Design Guidelines
  • Microsoft Guidelines
StonedStudio
  • 507
  • 3
  • 20
Nate Anderson
  • 18,334
  • 18
  • 100
  • 135
  • 35
    1) There is no inconsistency. "Id" is an **abbreviation**, not an acronym. 2) It depends on the context of the identifier, i.e., class, interface, attribute, enumeration type, static field, parameter, method, property or event. If the guideline for the identifier is using PascalCase, then it would be `USTaxes` and `PlayerId`; camelCase: `usTaxes` and `playerId`. 3) It would be `USId` in PascalCase, `usId` in camelCase, and `parseDbmXml` in camelCase. – Frederik Krautwald May 26 '15 at 13:44
  • 7
    You're right, it's an abbreviation. My point is that it should be UsTaxes, UsId. Two-letter "abbreviation or acronym" should not be treated differently than three-letters, or other "normal words." Other advice, from @Eonil's answer, is to avoid shorteners altogether. unitedStatesTaxes, or playerIdentifier. – Nate Anderson May 26 '15 at 18:24
  • The reason why Cwalina et al chose to treat two-character acronyms differently was primarily to avoid confusion. Take US taxes as an example: `TransferUSTaxes()` vs `TransferUsTaxes()`. Or using an example given in _Framework Design Guidelines_, `closeIOStream` vs `closeIoStream`. Abbreviations are discouraged. The only two exceptions are _ok_ and _id_. – Frederik Krautwald May 26 '15 at 22:12
  • Thanks for quoting Cwalina; I didn't realize the Microsoft link I quoted excerpted from [Framework Design Guidelines](http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613) . The Microsoft link does't rationalize why two-letters are an exception. The example they give is "IO". No word "Io" that I'm aware of. And I'm ambivalent with its advice encouraging use of acronyms, even if "well-known" – Nate Anderson May 28 '15 at 19:19
  • **Io**, _noun, plural_ **ios**: a small hawk, _Buteo solitarius._ **Io**, _noun_: 1) _Classical Mythology._ a woman loved by Zeus, identified by the Egyptians with Isis. 2) _Astronomy._ a large volcanically active moon of the planet Jupiter. **Io**, _Symbol, Chemistry_: ionium. **Io.**: Iowa. **I/O**: 1) inboard-outboard. 2) _Computers._ input/output. **I.O**: indirect object. – Frederik Krautwald May 28 '15 at 19:44
  • The _Framework Design Guidlines_ encourages neither the use of acronyms nor abbreviations. In fact, the authors are quite clear that they should be avoided, _unless_ their uses are well understood and doesn’t lead to ambiguity. – Frederik Krautwald May 28 '15 at 19:50
  • Microsoft does qualify, "Where appropriate...". And maybe someone would also confuse "System.Io" with my school mascot, the [‘io](http://blogs.scientificamerican.com/extinction-countdown/the-long-strange-saga-of-the-endangered-hawaiian-hawk/). So, I like your conclusion "they should be avoided, unless their uses are well understood and doesn’t lead to ambiguity". I admit "USTaxes" may register faster than "UsTaxes". Does Framework Design Guidelines say something about "two characters long"? – Nate Anderson May 28 '15 at 20:28
  • 5
    Ha ha. I doubt the confusion would arise - much - but the guidelines are, well, guidelines to prevent possible confusion. A contrived (bad) acronym example in a science context: `InIN(item)` vs `InIn(item)` (hint: IN is inch(es)). Or, `IDById(id)` vs `IdById(id)`, context science (hint: ID means infectious desease). "Two characters long" - what in which context? – Frederik Krautwald May 28 '15 at 23:14
  • 2
    At the [Microsoft link](https://msdn.microsoft.com/en-us/library/141e06ef(v=vs.71).aspx) "...use Pascal case or camel case for acronyms *more than two characters long*. ...However, you should capitalize acronyms that consist of *only two characters*..." That is the part I would call "inconsistent". Better characterization is "exception". And at least you've rationalized why two letter acronyms might be more confusion. But I guess those programs with "CanCan" are just out of luck; ambiguous whether it's the dance-move, or the Cercle de l'Aviron de Nantes' Community Area Network :) – Nate Anderson May 28 '15 at 23:41
  • Yes, that two-character acronym guideline is equivalent to the _Framework Design Guidelines._ Consistency is following guidelines consistently, inclusive guideline exceptions. I guess the "IO" eliminates that there is talk of a typing error: did he mean _In?_ – Frederik Krautwald May 29 '15 at 00:29
  • 33
    The author of [Capital Offense: How to Handle Abbreviations in CamelCase](http://www.approxion.com/?p=303) correctly invokes the term "abomination" when he writes: "While [using uppercase acronyms] works in simple cases, it leads to abominations when one abbreviation follows another: HTTPURLConnection, XMLIDREF" – kghastie Jul 14 '15 at 18:06
  • @kghastie Nice reference. That article references [Python's PEP-8](http://www.python.org/dev/peps/pep-0008/), which makes the abominable choice :) – Nate Anderson Jul 14 '15 at 19:16
  • love this answer. any criticism of Microsoft is welcome ;p – Line Oct 15 '18 at 14:28
  • 3
    @Frederik Krautwald: 1) There's an argument that "ID" was (at least originally) an *acronym* for "identity document" before it was hijacked to also mean "identification" or "identity". 2) This is a case where the natural language itself is being inconsistent (shocking, I know), because even if it were an *abbreviation*, almost all abbreviations are lower-cased (or at most proper-cased if they're of a proper noun which "identification" or "identity" are not) *not* all-caps. – Tom Oct 29 '18 at 17:14
  • 1
    Leaving two-letter abbreviations in all upper-case loses word boundaries, which are the whole point of the convention. – Denis Howe Jan 19 '21 at 15:38
  • 2
    @FrederikKrautwald When I was a young lad, I read an editorial that suggested always using using `as` for the "magic word" in type conversion-ish functions, as in `asIn()` _[sic]_ or `LengthAsIn()`. IIRC it was something to do with readability and consistency, possibly this was so long ago that people were writing `InchesFromMeters()` and nobody had invented `toString()` yet. Speaking of JavaScript, I hate writing `JSON` instead of `Json`, but I'll pay the price of consistency. The big problem with abbreviations vs acronyms is automated automated conversion functions can't discern. – Orwellophile Oct 14 '21 at 07:14
  • 1
    @Orwellophile I love that you brought up the `as` "magic word". Conversion-ish functions always suffer from inconsistency, e.g., `inchesToMeters()` vs `metersFromInches()`. I’m guilty of this myself. And then conventions that functions should be a verb: `calculateMetersFromInches()`. Whatever may be the guidelines in the project, I think `as` solves a lot. Many thanks. – Frederik Krautwald Oct 19 '21 at 20:17
  • 2
    @FrederikKrautwald it later got picked up by Rust as a conversion operation, and I have been know to define C++ class members with template that are simply called `as()`... eg: `circle.as()`.. but yeah, I agree, and I thank whomever wrote the article I read so many years ago. – Orwellophile Oct 22 '21 at 13:52
  • Also of note is that no-one has picked up that US (in its most common usage) is an abbreviation (of an acronym) not an acronym in and of itself. – Paul Childs Dec 05 '22 at 22:22
  • @PaulChilds nice point, I think you're saying "USA" is the acronym, and "US" is an abbreviation of the "USA" acronym. Some interesting points on the [abbreviation](https://english.stackexchange.com/questions/159018/the-usa-vs-the-us) and [omitting "of"](https://english.stackexchange.com/questions/249554/articles-prepositions-and-conjunctions-in-acronyms-and-initialisms) in the original acronym. And what about [anacronyms](https://en.wiktionary.org/wiki/anacronym), well I guess they're treated like full-fledged words now! – Nate Anderson Dec 10 '22 at 18:47
274

Some guidelines Microsoft has written about camelCase are:

When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.

Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.

Summing up:

  • When you use an abbreviation or acronym that is two characters long, put them all in caps;

  • When the acronym is longer than two chars, use a capital for the first character.

So, in your specific case, getUnescoProperties() is correct.

André Chalella
  • 13,788
  • 10
  • 54
  • 62
apollosoftware.org
  • 12,161
  • 4
  • 48
  • 69
  • 14
    I guess I should start using `ID` instead `Id` (which I use/see everywhere) – jasonscript Dec 19 '13 at 02:19
  • 44
    Technically "ID" isn't an acronym (it's an abbreviation of "identifier" or "identification"), but I don't really know how/if this guideline helps with that one. :-\ – bryant Apr 16 '14 at 04:23
  • 1
    Hmm, what about when using plural with acronyms? 'getUris()' doesn't sound great. – Vlad Ilie Jul 14 '14 at 07:43
  • 90
    I don't think this is a good standard. Distinguishing normal acronyms, two-letter acronyms, and normal words seems overcomplicated and contrary to the idea of having a consistent naming convention. – Sam Sep 16 '14 at 02:28
  • Also, giving acronyms special treatment seems silly since this is **camel** case, not English-case! – Sam Sep 16 '14 at 02:29
  • 59
    Also, being stated by Microsoft doesn't make something "correct". – Sam Sep 16 '14 at 02:31
  • 2
    What a stupid guideline by MS. – Josef Sábl Jun 03 '16 at 14:23
  • 80
    It's nice to know they follow their own guideline: [`XMLHttpRequest()`](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) originally came from Microsoft. :-) – Makyen Aug 07 '16 at 10:06
  • 1
    Agree that there should not be exception for 2-letter acronyms. See "DbContext" class. Looks better than "DBContext". – Rustem Zinnatullin Mar 21 '19 at 12:03
  • 1
    @jasonscript Since when is "Id" an acronym"? It is short for "identifier", so IMO you are already correct with "Id" vs. "ID". The latter is wrong. :) – Josh M. Apr 22 '19 at 12:37
  • @RustemZinnatullin "DB" Is not an acronym, nor is "Db" it is just shorthand for "database" of course, which is one word and hence not acronymizable, but is abrevable. :) – Josh M. Apr 22 '19 at 12:43
  • 1
    @Josh M, "ID" is an acronym for "Identifying Datum", so "Id" is clearly wrong :P [See](https://stackoverflow.com/questions/2109171/c-sharp-naming-conventions-for-acronyms#answer-2109187) – ttugates Sep 05 '19 at 13:07
  • 1
    @ttugates, in my world, "Id" is short for "Identifier". I guess it depends on what you're doing / working with. – Josh M. Sep 05 '19 at 20:12
  • What about 1-letter acronyms? – jbyrd Mar 05 '20 at 13:55
  • Abbreviating the words "identifier", "identity", "identification", etc. as "ID" with an upper case "D" (and, worse, pronouncing it /eye-dee/) is clearly wrong and intensely annoying. I guess people got confused with the abbreviation for "identity document" or some other multiword phrase, or the US state of Idaho (but almost certainly not "Identifying Datum", @ttugates). Or maybe they're worried about confusion with Freudian psychology, as in, "What's your id?", "The source of my impulses and primary processes." – Denis Howe Jan 19 '21 at 15:01
38

To convert to CamelCase, there is also Google's (nearly) deterministic Camel case algorithm:

Beginning with the prose form of the name:

  1. Convert the phrase to plain ASCII and remove any apostrophes. For example, "Müller's algorithm" might become "Muellers algorithm".
  2. Divide this result into words, splitting on spaces and any remaining punctuation (typically hyphens).
    1. Recommended: if any word already has a conventional camel case appearance in common usage, split this into its constituent parts (e.g., "AdWords" becomes "ad words"). Note that a word such as "iOS" is not really in camel case per se; it defies any convention, so this recommendation does not apply.
  3. Now lowercase everything (including acronyms), then uppercase only the first character of:
    1. … each word, to yield upper camel case, or
    2. … each word except the first, to yield lower camel case
  4. Finally, join all the words into a single identifier.

Note that the casing of the original words is almost entirely disregarded.

In the following examples, "XML HTTP request" is correctly transformed to XmlHttpRequest, XMLHTTPRequest is incorrect.

serv-inc
  • 35,772
  • 9
  • 166
  • 188
  • 1
    I appreciate this comment because it points to a well known example in common use today (XmlHttpRequest, despite its insanity, is everywhere on the web today). Yet, some philosophy may be in order for us here. As George Bernard Shaw said "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Coming from a Python community that is strong and happy, I propose unreasonably to adopt in my Python code for classes the equivalent of this: "XML_HTTP_Request". – legel Nov 22 '22 at 17:41
  • @legel: of course, snake case is more readable than camel case, but why not e.g. xml_http_request ? – serv-inc Nov 23 '22 at 09:08
  • 1
    Indeed, snakes > camels. The Snake_Camel is a monster I created to look like a Camel where only Camels are desired, but perform like a Snake. – legel Nov 24 '22 at 14:42
29

getUnescoProperties() should be the best solution...

When possible just follow the pure camelCase, when you have acronyms just let them upper case when possible otherwise go camelCase.

Generally in OO programming variables should start with lower case letter (lowerCamelCase) and class should start with upper case letter (UpperCamelCase).

When in doubt just go pure camelCase ;)

parseXML is fine, parseXml is also camelCase

XMLHTTPRequest should be XmlHttpRequest or xmlHttpRequest no way to go with subsequent upper case acronyms, it is definitively not clear for all test cases.

e.g. how do you read this word HTTPSSLRequest, HTTP + SSL, or HTTPS + SL (that doesn't mean anything but...), in that case follow camel case convention and go for httpSslRequest or httpsSlRequest, maybe it is no longer nice, but it is definitely more clear.

teradyl
  • 2,584
  • 1
  • 25
  • 34
luk_z
  • 451
  • 1
  • 8
  • 16
  • 14
    I like your `HTTPSSL` example, although SL doesn't mean anything, how about something like HTTPSSHTunnel? Is it HTTPS + SH (shell) or HTTP + SSH? Google convention is definitely less ambiguous. – L. Holanda Jun 20 '19 at 23:57
16

There is airbnb JavaScript Style Guide at github with a lot of stars (~57.5k at this moment) and guides about acronyms which say:

Acronyms and initialisms should always be all capitalized, or all lowercased.

Why? Names are for readability, not to appease a computer algorithm.

// 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
  • 5,163
  • 2
  • 33
  • 40
  • 23
    "_Why? Names are for readability, not to appease a computer algorithm_" so, ```XMLHTTPRequest``` is way better readable than ```XmlHttpRequest```, right? – L. Holanda Sep 12 '18 at 21:30
  • 8
    Doesn't make sense why `httpRequests` is considered good but `HttpRequests` is bad. following this principle then, for _XML HTTP Request_ should be `xmlhttpRequest`??? – L. Holanda Sep 12 '18 at 21:35
  • 10
    I often cite the AirBnb style guide, but in this case I don't agree. I particularly don't agree with their statement: "Acronyms and initialisms should always be all uppercased, or all lowercased.". `xmlHttpRequest` is more readable than `XMLHTTPRequest` in my opinion. – RonanCodes Feb 26 '20 at 15:23
  • 1
    What do you think of 'LASER', 'RADAR', "SCUBA"?They were acronyms, but nowadays they are considered as normal words widely. – chen3feng Nov 17 '20 at 07:20
  • When you use a capitalized acronym, you basically transform it into a word by itself, which I don't think is right. Acronyms should be either all uppercased or lowercased. – Temperosa Jan 02 '21 at 17:44
  • @chen3feng What about self referencing acronyms like `GNU is Not Unix` :p – Orwellophile Oct 14 '21 at 07:22
  • Readability is a quality clearly not understood if a style guide uses the word "always" – Paul Childs Dec 05 '22 at 22:30
5

In addition to what @valex has said, I want to recap a couple of things with the given answers for this question.

I think the general answer is: it depends on the programming language that you are using.

C Sharp

Microsoft has written some guidelines where it seems that HtmlButton is the right way to name a class for this cases.

Javascript

Javascript has some global variables with acronyms and it uses them all in upper case (but funnily, not always consistently) here are some examples:

encodeURIComponent XMLHttpRequest toJSON toISOString

lante
  • 7,192
  • 4
  • 37
  • 57
1

Currently I am using the following rules:

  1. Capital case for acronyms: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

  2. Camel case for abbreviations: ID[entifier], Exe[cutable], App[lication].

ID is an exception, sorry but true.

When I see a capital letter I assume an acronym, i.e. a separate word for each letter. Abbreviations do not have separate words for each letter, so I use camel case.

XMLHTTPRequest is ambigous, but it is a rare case and it's not so much ambiguous, so it's ok, rules and logic are more important than beauty.

0

The JavaScript Airbnb style guide talks a bit about this. Basically:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Because I typically read a leading capital letter as a class, I tend to avoid that. At the end of the day, it's all preference.

Bryantee
  • 474
  • 1
  • 6
  • 12
0

disclaimer: English is not my mother tone. But I've thought about this problem for a long time, esp when using node (camelcase style) to handle database since the name of table fields should be snakeized, this is my thought:

There are 2 kinds of 'acronyms' for a programmer:

  • in natural language, UNESCO
  • in computer programming language, for example, tmc and textMessageContainer, which usually appears as a local variable.

In programming world, all acronyms in natural language should be treated as word, the reasons are:

  1. when we programming, we should name a variable either in acronym style or non-acronym-style. So, if we name a function getUNESCOProperties, it means UNESCO is an acronym ( otherwise it shouldn't be all uppercase letters ), but evidently, get and properties are not acronyms. so, we should name this function either gunescop or getUnitedNationsEducationalScientificAndCulturalOrganizationProperties, both are unacceptable.

  2. natural language is evolving continuously, and today's acronyms will become words tommorow, but programs should be independent of this trend and stand forever.

by the way, in the most-voted answer, IO is the acronym in computer language meaning (stands for InputOutput), but I don't like the name, since I think the acronym (in computer language) should only be used to name a local variable but a top-level class/function, so InputOutput should be used instead of IO

xiechao06
  • 410
  • 6
  • 9
-1

There is also another camelcase convention that tries to favor readability for acronyms by using either uppercase (HTML), or lowercase (html), but avoiding both (Html).

So in your case you could write getUNESCOProperties. You could also write unescoProperties for a variable, or UNESCOProperties for a class (the convention for classes is to start with uppercase).

This rule gets tricky if you want to put together two acronyms, for example for a class named XML HTTP Request. It would start with uppercase, but since XMLHTTPRequest would not be easy to read (is it XMLH TTP Request?), and XMLhttpRequest would break the camelcase convention (is it XM Lhttp Request?), the best option would be to mix case: XMLHttpRequest, which is actually what the W3C used. However using this sort of namings is discouraged. For this example, HTTPRequest would be a better name.

Since the official English word for identification/identity seems to be ID, although is not an acronym, you could apply the same rules there.

This convention seems to be pretty popular out there, but it's just a convention and there is no right or wrong. Just try to stick to a convention and make sure your names are readable.

Jesús Carrera
  • 11,275
  • 4
  • 63
  • 55
  • 3
    I don't believe this whole thread :-) So it would be XMLToHtmlConverter but HTMLToXmlConverter? Wow... – Josef Sábl Jun 03 '16 at 14:28
  • 1
    @JosefSábl, yes, it would be like that. Regarding your downvote, I'm not saying I like this convention, but it definitely exists. – Jesús Carrera Jun 03 '16 at 14:59
  • 1
    I read the question as "What is good convention of writing Accronyms in camel case" not "Can you list all conventions that exist". And as I consider your mentioned convention as very bad, I downvoted :-) – Josef Sábl Jul 04 '16 at 14:31
  • Well the question is "Is it right to write it this way?", and since there are many "right" ways to write it because it's just a convention, and this convention is quite popular (regardless of how you consider it), my answer is very valid :-) – Jesús Carrera Jul 04 '16 at 16:09
-1

UNESCO is a special case as it is usually ( in English ) read as a word and not an acronym - like UEFA, RADA, BAFTA and unlike BBC, HTML, SSL

user1833431
  • 37
  • 1
  • 1
  • 1
    This is is the distinction between "acronyms" and mere "abbreviations"; this distinction would seem to be relevant to the whole discussion, but has been almost entirely elided in the answers presented. – simon Oct 31 '16 at 17:51
  • 2
    BBC, HTML, SSL, and other acronyms where you sound out each letter are more accurately called initialisms. Words like UNESCO that are pronounced as a word are true acronyms. – Lrdwhyt Jan 31 '20 at 12:12