The CamelCase notation is one of the most popular word separation schemes. It used to be my favorite as well, but these days, I happen to prefer underscores, just like Kernighan and Ritchie did. But this is just my personal taste and it might be subject to change. I certainly don’t want to convince you to change your style. As always, it is more important to follow one style consistently than trying to find the “best” style.
Speaking of consistency, if there is one clear downside of CamelCase, it’s that it seduces people into being inconsistent — at least if abbreviations (or acronyms) are used. Take a look at some real-life examples from the Java API:
1 2 3 4 5 6 7 |
HTTPException HttpURLConnection XMLFormatter XmlID XmlIDREF |
But what an inconsistent mess this is! Followers of the CamelCase school of thought obviously have difficulty deciding how to handle abbreviations. In some cases, an abbreviation is written all-uppercase, in other cases only the initial character is capitalized. To avoid such mixes, some coding conventions, like Python’s PEP-8, try to cure this by giving explicit advice:
When using abbreviations in CapWords, capitalize all the letters of the abbreviation. Thus HTTPServerError is better than HttpServerError.
I totally disagree. While it works in simple cases, it leads to abominations when one abbreviation follows another:
1 2 3 4 |
HTTPURLConnection XMLIDREF |
The only convention that works reliably is this: “Treat abbreviations just like ordinary words”. That is, don’t use all-capital letters:
1 2 3 4 5 6 7 |
HttpException HttpUrlConnection XmlFormatter XmlId XmlIdRef |
This works also if identifiers have to start with a small letter (e. g. names of local variables):
1 2 3 4 5 6 7 |
httpException httpUrlConnection xmlFormatter xmlId xmlIdRef |