2

Ok, I understand what CamelCase is. This question is relating to how to CamelCase the shortened version of Property List (PList). I am asking this because I am working on a PList parser in C# and knowing how everything in .NET is CamelCase, I am wondering, should it be PList or Plist (also why)?

9

The rules for Pascal Casing in .NET are about as follows:

  • acronyms and abbreviations of one or two letters are all-uppercase (XPath, ACCurrent, VWBeetle)
  • full words and abbreviations of three or more letters have one uppercase letter and the rest lowercase (XmlDocument, AspLover, BmwDriver)
  • note that two-letter words that are not abbreviations are first-uppercase, not all-uppercase: StopAndGo, not StopAndGO
  • also note that the original capitalization of a word (even a brand name) is never honored unless it coincides with the above rules: IPhone, not iPhone, Asp, not ASP, DotNet, not DotNET.

Since the 'P' is short for 'property', and 'list' is a full word, the correct capitalization is PList. Plist would suggest that 'plist' were one word, which it isn't. (And the reader knows it has to be P-list, not PL-ist, because if 'ist' were a full word, it would have to be PLIst.)

2

In the case of OS X property lists they are usually referred to as ".plist" or "Property List." I would recommend not using the shortened version because that is not the actual name of the file type, but the extension.

.NET is not actually CamelCase, but Pascal Casing; camel casing traditionally has the first letter be lowercase and further letters uppercase, while Pascal case has the first letter be uppercase. You may remove the rest of a word and retain the uppercase (as in "PList") but you shouldn't do that anyway, because its less descriptive. Additionally, .NET casing style requires that any acronym that is three or more letters be lowercased after the first letter, such that "Graphics Display Interface Tool" would be "GdiTool", NOT "GDITool".

  • Yes, but it is not System.ExtensibleMarkupLanguage now is it? – Cole Johnson Jun 17 '12 at 4:41
  • 1
    It's also not System.XMLanguage either ;) – Skrylar Jun 17 '12 at 8:24
  • The problem with the PList or Plist is very specific. "P" is a shortcut for Property. In this case, when you develop "clean development" it should be PropertyList, otherwise if you are using P as a prefix it should be uppercase and the "list" is a new word so uppercase too. – Smokefoot Jun 17 '12 at 11:10
1

The camel case convention suggests that each distinct word joined into an identifier should have its first character capitalized. So for public .NET identifiers, I would go with PList.

(the convention in .NET for private identifiers is to start with a lower case character though, so for class or routine variables it would be pList).

1

You know something's wrong when you worry over such trivialities. Choose whichever one suits you best and get back to worrying over making the code work.

1

My way to avoid spending much time thinking about such things is just ask myself how I'd name it in underscore, and I do unfortunately clash a bit with developers on this. But I can at least say that it requires little thought, and I don't think that's a particularly subjective argument. So if you do it like me, the question is how you'd write "p list" or "plist" in underscore convention.

Would you write like p_list or plist? Then it becomes a rather simple translation from underscore to camel case that even a robot can do.

Similar thing for like "USA infantry". Would I write it like this?

usa_infantry -> UsaInfanty (machine translation)

Or like this?

u_s_a_infantry -> USAInfantry (machine translation)

Take "Renderer GL". Would you write it like this?

renderer_g_l -> RendererGL (machine translation)

Or like this?

renderer_gl -> RendererGl (machine translation)

That's how I do it anyway. Some people don't like how I do it with abbreviations since I don't capitalize all the letters if they're grouped together (disregarding English "aesthetics") in favor of what seems the most natural translation of the underscore rep, but at least I can say it requires the least amount of thought and therefore promotes the greatest amount of consistency among loosely-coordinated developers if they apply the same practice. Meanwhile I see popular APIs like QT with conventions that aren't consistent at all mainly with their abbreviations, whereas I can at least claim that if the developers used my "underscore translation" technique, they'd have little difficulty with consistency in the use of camelCase.

This might all be argued away as trivialities, except for the consistency part within teams. If you're shipping an SDK and the naming conventions really look like different people named everything, then that does translate to a usability and familiarity issue to third parties as well as looking somewhat sloppy and unprofessional which isn't so trivial, which ended up becoming a source of third party complaints which ended up becoming a source of time-sink arguments between devs. And a coding standard which is very nuanced with lots of exceptional cases is often bound to not be followed so well by developers unless they're very tightly collaborated (and I've not always had the fortune of working with such teams). So I favor as close to the "no-brainer" standard as I can, and this idea of translating to underscore convention and then robotically translating to camelCase or UpperCamelCase at least tends to reduce the tendency for developers to vary quite a bit in how they apply that convention.

In particular I developed this style to camelCasing in a vain hope of ending stupid arguments over how we name things, specifically when abbreviations or acronyms are involved, only to find my no-brainer solution still contested from an "English aesthetic" standpoint (why don't they contest this for underscore convention?). Oh well, shrug. It's the best I was able to come up with to promote greater consistency in how my team, and maybe some small glimmer of hope for the rest of the world, uses camel casing, because I noticed much fewer disputes of this sort with underscore_convention (it doesn't solve everything but at least we're not arguing about acronyms typically). In my team we even had SDK identifiers with underscore and camelCase convention mixed together, like FastRenderer_GL, which in my opinion looks dumb as hell and is hard to remember when developers get so nuanced with the personal exceptions they apply to their identifiers that no one else understands. I hope I don't come across as dogmatic in this regard since my whole goal in coming up with this approach was to get us to focus on shipping things instead of arguing about how we name things (though sometimes I inadvertently get dogmatic in my quest for anti-dogmatism).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.