Camel casing acronyms?

This question may seem pedantic or just silly, but what is your practice for camel casing when it comes to acronyms? Do you insist that开发者_如何学JAVA everything, even acronyms must be camel cased, or do you make an exception for acronyms. Explanations would be great too. I'm not sure how this practice effects IDE features (autocomplete) or what the industry standard are.

For C#, check out Microsoft's guidelines:

Do capitalize both characters of two-character acronyms, except the first word of a camel-cased identifier.

A property named DBRate is an example of a short acronym (DB) used as the first word of a Pascal-cased identifier. A parameter named ioChannel is an example of a short acronym (IO) used as the first word of a camel-cased identifier.

Do capitalize only the first character of acronyms with three or more characters, except the first word of a camel-cased identifier.

A class named XmlWriter is an example of a long acronym used as the first word of a Pascal-cased identifier. A parameter named htmlReader is an example of a long acronym used as the first word of a camel-cased identifier.

Do not capitalize any of the characters of any acronyms, whatever their length, at the beginning of a camel-cased identifier.

A parameter named xmlStream is an example of a long acronym (xml) used as the first word of a camel-cased identifier. A parameter named dbServerName is an example of a short acronym (db) used as the first word of a camel-cased identifier.

Personal preference.

I tend to do it just because it doesn't merge well with other words, like, XMLHTTPParser, compared to XmlHttpParser. Do whatever makes you feel good, but do it in a standard way.

Here's what i like, and this is for Java: classes start with upper-case, fields with lower case, and acronyms do not affect that. That leads to things that look like this,

UrlConnection urlConnection;

The problem is that if you try to apply a rule where you always upper case acronyms, or even the first letter of an acronym irrespective of it being a field or class name, you get strange things like,

URLConnection URLConnection; // huh?

In other words, the field starts with lower case rule contradicts with a hypothetical uppercase acronym rule. You can't apply them both.

Even the Java SDK has examples of both, within a single class name: HttpURLConnection. You'd think it would be either HTTPURLConnection or HttpUrlConnection.

In general, treating acronyms the same as the overall word case is the most intuitive, for the following reasons.

1. It helps avoid memorization of a bunch of special rules (case in point, the MS guidelines above)
2. The lettercase of specific terms may change over time or between personal interpretations like with posix, unix, regex, radar, scuba, laser, and email
3. It can otherwise get visually clunky when you need to deal with (and/or combine) tech terms like miniiOSLayout, SSHHTTPSSession, CPUURLLinkC, and schemaeBay (granted these specific examples are unlikely, they help illustrate the problem)
4. It removes some confusion if the language uses different cases for different things, like capitalizing AClassName but not anObjectName

Yes, httpUrl looks dumb. But the more you code, the more you're likely to realize the above points on your own. And while not a huge deal in and of itself, a lot of little things can add up and create frustration with your work.

We have no hard & fast rule, but we generally do not camel case acronyms. A few with more than three letters are but most aren't.

Generally, our acronyms are PascalCased or camelCased as most have stated.

Some exceptions:

• If an acronym used in a member name is well known in the business for which the software is being written, and it is a true acronym (the capital letters form a dictionary word, as opposed to just an initialism like XML), we often capitalize it to avoid confusion with the dictionary word.

• Sometimes in ORMs working against existing DBs, I've just named the mapped variable the same as the DB column, capitalization and all, rather than having to map FdicId => FDICID explicitly in a case-sensitive DB. This does have its downside, as future developers can silently break functionality if they feel more strongly than I did that it should be properly cased, but didn't know why.

• ID is a bit of a flip-flopper when used on the end of a member name; Whether it's ID or Id depends on the developer who writes the first such member in a class or namespace, and they're seldom revised.

Depends on the length of acronyms also.

DB--->looks decent

openDBConnection

HTTP--->looks odd

openHTTPCConnection

Apart from rules:

• Readability matters a lot to me.

• Consistency shows your effort on programming.

So, do it consistent and legible.