Casing for acronyms

In the comments of a recent post Frank Hileman suggests:

I have seen, with acronyms, anything goes. I assumed there is no rule.


We do have a rule and I believe it is reasonably well followed in the Framework.

            Do use PascalCasing or camelCasing for any acronyms over two characters long. For example, use HtmlButton rather than HTMLButton but System.IO instead of System.Io.


I admit that the one and two letter special case is a bit odd, but it is certainly an easy to follow rule and, I believe results in more expected API casing… I mean don’t you think System.Io and HTMLButton look bad?

Comments (18)

  1. Shane King says:

    No, I think System.Io looks a lot better than System.IO.

    Multiple capitals in a row always looks bad to me. Even only 2 of them. They’re also harder for me to type than single caps. Plus it seems a needless exception to make for 2 letter words.

  2. Tim Marman says:

    We follow that naming convention internally (based on the MS Design Guidelines), but I’m not a huge fan in all situations.

    Take our base namespace, made up of two acronyms: company name (2) and dept (3).

    This convention makes the namespace we use AB.Cde, which I just think is a bit awkward.

    Personally, I think the capitilazation rule should only apply when the acronym is used in conjunction with another word, but should always be all caps when used by itself.

    In other words:

    System.XML, System.IO, System.XML.XmlWriter

    System.IO, AB.CDE.Fghi


  3. Frank Hileman says:

    Sorry about raising that thread again. Unfortunately, I will probably forget the rule, whatever it finally is. I prefer Pascal casing for all acronyms, so I’ll use that. I imagine people will ignore any rule here — seems to be a lot of disagreement.

  4. Eric says:

    The simpler the rule, the better. There’s no reason to special-case acronyms. Many people find "Xml" initially ugly, but like all things it grows on you and you move on. I don’t find "System.IO" particularly attractive either over "System.Io".

    The linguistic discussions over whether something is an acronym or not shouldn’t be required when naming a method.

  5. Mark Cidade says:

    I feel that System.IO is better than System.Io. That might be because the last letter is a vowel. If it was something like Protocols.IP, that would look better than Protocols.Ip. But then, I would prefer Protocols.IpTcp over IPTCP or IPTcp. I’m just using IP/TCP as an example, though I know it’s better known as TCP/IP.

    The .NET framework breaks the rule in System.Data with IDbConnection and the like, but I think that looks better than IDBConnection. The interface "I" prefix adds to consecutive caps, as does the fact that there’s another word after DB.

    I’ve changed my own Db* classes to DB. I think there’s more to be said for global consistency than local asthetics. Maybe the rule should be "ACRONYMS should be PascalCased unless it’s only two letters long, in which case it should be all caps, except for when it ends in a vowel and is not at the end of a CompoundName, or it ends in a consonant and is at the end of a namespace. EXAMPLES: Html.AA.Nw, HtmlAaNW, HtmlNwAA"

    Or maybe not.

  6. moo says:

    Here is a better rule, do what works best for your solution.

    System.IO SHOULD be written like that according to the design guidelines, only acyonms with 3 letters or more should be cased like Tcp instead of TCP and DB instead of Db.

    Anyway, I do whats more readable for MY solution, I dont stick my head in the oven just because somebody else does.

  7. Nicko says:

    Database is a dictionary word, therefore "Db" is not an acronym it is an abbreviation.


    acronym = [a word formed from the initial letters of a multi-word name]

    abbreviation = [a shortened form of a word or phrase used chiefly in writing to represent the complete form]

    Abbreviations should follow Pascal casing and do not have the two character exception that acronyms have.

    Unlike "IO", therefore, "Id", "Db" etc… should not be all caps.

  8. moo says:

    Dont be such an anal retentive.

    Meanwhile back in the real world, people have been found ot be doing what works best for them, after all its theyre solution for theyre problem domain. Gasp.

  9. One of the ones I’ve seen cause more trouble is ID…. some API names say "ID" while others "Id".

    Acronyms are only one side of the coin… if you want the API consistent, you should consider what to do with abbreviations, also.

  10. marklio says:

    The current guideline made alot of sense to me at first, but after having to explain it multiple times for my collegues, I’m starting to wonder where the value is in the exception for 2 letter acronyms.

    There’s alot of truth to the point that things like DB and ID aren’t acronyms, but abbreviations, which may lead to further confusion.

    There’s also the problem with plurality. If I have multiple ID’s, does the name become IDs or Ids? I don’t have a solution, but there’s value in a unified guideline.

    My suggestion is to drop the special case for acronyms and always use Pascal case.

  11. nfactorial says:

    I didn’t like this rule to begin with, but it has grown on me and I’m now very happy with it. Yes, System.Io and HTMLButton do look bad to me. Though the one and two letter special case seems to work only for namespace names. I would probably prefer IoButton over IOButton 🙂

    I must confess that I do currently break the casing recommendations in one instance, my namespaces currently all reside within a root ‘nfactorial’ namespace which I have only found satisfactory as lowercase. That still niggles me though….


  12. moo says:

    I lable things as it fits the situation, I do hate UPPERCASE its just so VT100 and COBOL.

    We need case cues to clearly read quickly. It should be used to identify the start and end of items (like words). If you want other information thats where metadata comes into play (intellisense).

    We are past the days of notepad.exe and vi or emacs.

  13. Just another case to consider: Multiple abbreviations. Sometimes, multiple words are put together, and then abbreviated, like (as mentioned a while ago) Red, Green, Blue, Alpha. This *should* be RGBA because each letter is the beginning of a separate abbreviation. It’s not an acronym, nor a single abbreviations. The guidelines cover this (PascalCase each abbreviation), although perhaps it is not clear to some.

  14. moo says:

    IF there is a well known term or abreviation, like mathematics, metalurgy , chemestry etc use those over some geek’s idea for notation.

    Just as you use i , j or k for loop counters and indexers, use well known names for the problem domain at hand.

    It also means you can sit down with the debugger with the non computer specalist in that field with theyre calculator and they can step thru it also, invaluable.

  15. Tom McKearney says:

    ASP.NET ?? 🙂

  16. Tom B. says:

    How about System.Text.Encoding.ASCII, System.Text.Encoding.UTF8, etc.? I’m surprised there’s such a blatant incosistency in the FCL.

  17. Capitalization: Should you use ID or Id