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

• Anonymous
  February 07, 2004
  The comment has been removed
• Anonymous
  February 07, 2004
  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
  
  Thoughts?
• Anonymous
  February 07, 2004
  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.
• Anonymous
  February 07, 2004
  
  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.
  
  
  
  
• Anonymous
  February 07, 2004
  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.
• Anonymous
  February 07, 2004
  The comment has been removed
• Anonymous
  February 07, 2004
  Database is a dictionary word, therefore "Db" is not an acronym it is an abbreviation.
  
  where:
  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.
  
• Anonymous
  February 07, 2004
  The comment has been removed
• Anonymous
  February 07, 2004
  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.
• Anonymous
  February 08, 2004
  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.
• Anonymous
  February 08, 2004
  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....
  
  n!
• Anonymous
  February 08, 2004
  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.
  
  
• Anonymous
  February 10, 2004
  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.
• Anonymous
  February 10, 2004
  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.
• Anonymous
  February 17, 2004
  ASP.NET ?? :-)
• Anonymous
  March 04, 2004
  How about System.Text.Encoding.ASCII, System.Text.Encoding.UTF8, etc.? I'm surprised there's such a blatant incosistency in the FCL.
• Anonymous
  August 12, 2004
  Capitalization: Should you use ID or Id