Acronyms in CamelCase [closed]

Question

I have a doubt about CamelCase. Supose 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();

Answer 1

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.

Answer 2

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. Votes can decide. 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 I 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 Taxes → usTaxes
• Player ID → playerId

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.

And in searching for the "popular" answer in existing code or markup, maybe the accepted answer got it right.

• See "EDXML" in this XML schema
• See "SFAS158" in this XBRL schema

Answer 3

First, I have to clarify that I am not a native English speaker, so my claim about English grammar can simply be wrong. If you discover such errors, please let me know, and I will be very thankful.

---

Best practice for acronym would be avoiding acronyms as much as possible. Anyway, this is not the case because acronym UNESCO is more familiar than full name UnitedNationsEducationalScientificAndCulturalOrganization.

Then, I think UNESCO makes more sense than Unesco because simply it's closer to real life form so more familiar. I had some trouble to figure out what the word Unesco actually means.

As an another example, think about Arc. This sounds like a curve around a circle, but in Rust, this means Atomically Reference Counted. If it's been written like ARC, at least readers would recognize that the word is an acronym of something else rather than a kind of curve.

Modern programs are written mainly for human readers. Then those naming rules must be set for human readability rather than machine processing or analysis.

In this perspective, we lose some readability by using Unesco over UNESCO while gaining nothing.

And for any other cases, I think just following plain English acronym rules (or conventions) is enough for most cases for best readability.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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

Answer 9

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.

Answer 10

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

Answer 11

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.

Answer 12

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