Accueil > professional > Camel case: trying to clear the matter of uppercase abbreviations/acronyms

Camel case: trying to clear the matter of uppercase abbreviations/acronyms

[Article aussi disponible en français.]
Small entry about an issue which showed up already a few times in our team: shall acronyms be uppercases or not when part of a camel case name ? To put it differently, would you go for XMLFileName or XmlFileName ?

And then, what about abbreviation, like a component for some Front Office, with this Front Office being often referred to as FO (or Fo ?). Should this component be named FOFileName or FoFileName ? SomeDataFODisplay or SomeDataFoDisplay ?

Sounds pointless isn’t it ? We’re there to produce working software, and it doesn’t matter how you call your components. Yet, when using IDE like Eclipse which allows « camel case aware file name completion », like the open type dialog, one has to know which way to go. Basically, you have to agree on some team wide convention and be done.

But then, due to this kind of « pointlessness » aspect of the topic, we never dealt properly with it, rather quickly agreeing for one way and then the other, based on « quick guts feeling ». And each way I felt like some were disagreeing with the choice, with no argument given to convince anyway.

As I hate this kind of groundless discussion, I took my nice editor and tried out.

For me, it looks like that:

  • keeping all upper case:
    + in line with the acronyms themselves, it’s XML not Xml.
    – becomes unreadable when combined, FOXMLRMIConfig is pretty blurry.
    – sucks with variables’ name. How to handle the common « private Foo foo » use case ? « private FOXMLData FOXMLData » ? Ugly. « private FOXMLData fOXMLData » ? Even worse ! « private FOXMLData foXMLData » ? A tad better, but still no great IMO.
  • keeping only the first letter uppercase:
    + no brainer for variables names. « private FoXmlData foXmlData » just feels right.
    + Can be combined ad nauseum. FoXmlRmiConfig is readable.
    – strange at first look. It’s HTML and PDF, not Html and Pdf damn it !

Over all, it looks like keeping only the first letter uppercase is the best way to go.

As I didn’t want to ignore « previous art », I tried to find out the « official » recommendation(s). I just found some from Microsoft, on the Capitalization Conventions page, in the paragraph « Capitalization Rules for Acronyms ».

To keep it short, what they say basically is:

  • Abbreviations:
    do not use any apart for ID and OK, which « In Pascal-cased identifiers they should appear as Id, and Ok. If used as the first word in a camel-cased identifier, they should appear as id and ok, respectively. »
  • Acronyms:
    – if 2 char long: keep them upper case, « except the first word of a camel-cased identifier ». Which means go for « private IOFile ioFile ».
    – if more than 2 chars, keep only the first letter upper case, except the first word of a camel-cased identifier. Which means « private XmlFile xmlFile ».

This 2 char rule is quite a surprise IMHO. I feel like it could help satisfy all parties on the topic. Yet I find it a bit awkward and overdone. And if « private DBXml dbXml » is the right way to go, then it feels completely mix up.

I wasn’t able to find Java/Sun/Oracle opinion on the topic. If ever you know it, let me know 🙂

As such, this 2 char only extra rule didn’t convince me. I would stick to the « only first letter uppercase rule » all over the place.

If you have a different opinion, I would gladly read it.

This being said, enough, or even already too much, wrote on the topic. Heading to bed !


EDIT : I just discovered recently the Google Java Style guideline, which says the same on camel case. Sweet 🙂

Étiquettes : , , ,
  1. Ghyz
    février 9, 2012 à 3:21

    I totally agree with you.
    Thanks for the article.

    HttpURLConnection really pisses me off for its lack of consistency (it’s the real name in the Java API). It should be HttpUrlConnection IMO.
    I think that private HTTPURLConnection hTTPURLConnection; proves that the « keep all uppercase » approach is flawed and not viable.

    Another way to see it (that is the same as the keep only the first letter uppercase approach) : if your acronym is in Wikipedia, you should consider it as a normal word and camel case it normally as any other word. If it’s not in Wikipedia either add it (if it makes sense) or explode the acronym so that other programmers can actually understand the code! In other words: don’t use acronyms unless EVERYONE will understand them. I hate custom acronyms, it makes the code difficult to maintain. Most acronym makers don’t even remember what their acronyms stands for when you ask them.

  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l'aide de votre compte Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )


Connexion à %s

%d blogueurs aiment cette page :