Acronyms in CamelCase

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.

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.

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 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.

( 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")

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

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