What’s in a Name? (Part II)

Our story so far:

  • Mono-cased variable and function names are holdovers from programming’s Jurassic Period, and should be regarded as extinct.
  • Mixed case variable and functions names are a good idea (duh).
  • Hungarian notation has its lure, and maybe its usefulness in some limited ways, but as a rule, not a good idea.

Can’t believe all those words boiled down to just those three things.  (Maybe I am a bit too verbose. :-P ) Last time I mentioned that mixed case variables are superior, and the world of development generally would agree that NumberOfItems is preferable to:

  • numberofitems
  • NUMBEROFITEMS
  • NUMBER_OF_ITEMS (but I bet there’s some COBOL geek out there who sees nothing wrong here)
  • number_of_items (but I bet there’s some UNIX geek out there thinking this ain’t so bad!)
  • noits
  • ni

as well as whatever other ways you might masticate the words for a variable that’s suppose to contain a count of the number items you have.  And yes, iNumberOfItems can’t come to the party either, it’s just a bit old fashioned and should be left to float out on a raft among the ice floes.  Sorry.

Now that we’re signed up for the Mixed Case Army, we can all just march along in lock step and always enjoy the same convention no matter what language or platform we code in, right? Not so fast.  There seems to be two schools of thought, even in this obscure cul-de-sac of nit-pickery:  the School of Camel Case, and the School of Pascal Case.  Using my favorite variable name from above, the two schools would render the name this way:

  • Camel Case: numberOfItems
  • Pascal Case: NumberOfItems

Yes, that’s right, there’s but one difference, regarding the case of the first character, “n” in this case.  (No pun intended–it just happened.)  The origins for the terms “Camel” and “Pascal” are known to the cognoscenti, but are nevertheless too pedantic to review, even here.

If you had to pick up code samples from various platforms and languages, you might find that Camel Case is prevalent in the UNIX/Java world, while Pascal Case seems to be more prevalent in the Windows/C# world.  There are exceptions.  E.g. the aforementioned .Net Framework coding guidelines recommend Pascal Case for everything, except parameter names.  The also aforementioned Java guidelines dictate Camel Case be used for variable and function names, but Pascal Case for class and interface names.

But I have a small problem with Camel Case, and it’s this:  it makes no sense.  In English (and let’s face it, most, if not all, computer languages are based in the English language) you never begin something with a lower-case letter.  (OK, e. e. cummings aside, but what the hell did he know about programming, anyway?)  A sentence starts with a capital letter.  A title starts with a capital letter and every other major word (other than articles and prepositions) is capitalized.  The menu items on my WordPress (not wordPress) admin panel begin with capitals.

In our Hungarian days, variable names did begin with a lower case letter, but that was because it was a prefix and not part of the name proper.  That made some kind of sense to keep the actual name more in focus.  But to arbitrarily dictate that only the internal words of a variable’s name are capitalized seems like a throwback those halcyon days when they just did everything in lower case because upper case letters were just, oh I dunno, so LOUD.

Why start a variable or function name this way?  Why not make the last character uppercase, or only vowels, or some other arbitrary selection?  Readability can’t be a factor here.  I’d concede that neither Camel nor Pascal is more readable, but with a gun to my head, I’d pick Pascal, only because it’s more natural.  So I just cannot fathom the mindset of the first person who decided that Camel case was a good idea, nor the herd of sheep that have followed him down this path.

Let me lay off the UNIX/Java stuff for now, before I say something really stupid, and just focus on the Windows/C# side to make my point.  (Let me give a shout out to VB here who has always, since I’ve was doing VB4 anyway, carried the torch for first-letter-caps, even to the language keywords.  W00t, w00t!)

So the .Net Framework guidelines specify 11 types of identifier: Class, Enumeration type, Enumeration values, Event, Exception class, Read-only static field, Interface, Method, Namespace, Parameter, and Property.  Of these Pascal Case is recommended for 10 and Camel Case for 1–Parameter.  Hmm.  Why just one?  Why is that situation so special that it demands a special (and illogical) requirement? I have one idea.  I run into this a lot when I am coding a class, particularly constructors.  I think I can make the simplest case by devising a small, immutable class.  Let’s call this the Person class, and all it has are public properties of FirstName, LastName, and PhoneNumber.  (Not really useful, but play along with me.) So in C#, I might define this this way:

public class Person
{
    public readonly string FirstName;
    public readonly string LastName;
    public readonly string PhoneNumber;
}

Since I’m digging immutable objects these days, I can only set the properties via the constructor, so I might code it this way:

public Person(string FirstName, string LastName, string PhoneNumber) // Ctor #1
{
   this.FirstName = FirstName;
   this.LastName = LastName;
   this.PhoneNumber = PhoneNumber;
}

IMO, this is a perfectly simple, readable, clear piece of code. Yet, the Framework camels would insist you do this:

public Person(string firstName, string lastName, string phoneNumber) // Ctor #2
{
   this.FirstName = firstName;
   this.LastName = lastName;
   this.PhoneNumber = phoneNumber;
}

If you’re paying attention, you will realize in this case that “this.” is unnecessary since C# is case-sensitive (another abomination I will rail about in some later post), but the guidelines clearly state that you should not have two variables that are distinguished only via case, i.e. FirstName and firstName.  Now if you were using Hungarian notation for the parameters (e.g. strFirstName),  then there would be no conflict, but I think we’ve put that to rest.  (Well, at least I’ve tried.)

If we had private member variables or fields behind the public properties, then scope prefixes for the member variables (e.g. m_FirstName) would work as well, but staying with our original simple case, I think Ctor #1 is good enough as it is, whilst Ctor #2, is painful to behold, even more so if you eliminate the “this.” prefix and force the reader to do a double-take.

I don’t want to beat a dead horse here (or a dead camel), so can we please stop the nonsense with this camel case once and for all?  Pascal case does its job just fine, and I cannot see any reason for inflicting an unnatural convention in one of eleven cases (parameters) in the .Net world.  Even though Java has more uses for camel case, prevalence does not cure absurdity.  But since I don’t have to work in that arena, I will opt out of that particular area of combat.

Perhaps we as developers need to focus on making clear, concise, and descriptive identifiers and stop trying to sneak added significance into them via Hungarian notation or obscure casing conventions.  We’re not writing code with notepad or vi any more.  (Yes, I know there are still legions of Luddites out there who swear that vi or emacs is the only code editor they need.   I pray for them.)  We have, or should have, an IDE that remembers for us the type and scope of all our identifiers.  If not, then we’re not working with the right tools.  Sure, a skilled carpenter can still build a bookcase using hand tools, and that bookcase might be very beautiful and functional, but if I’m that carpenter, and I want to compete in today’s business environment, I’d better get out to Home Depot and buy me some power tools, otherwise I soon will be a very skilled and very broke carpenter.

I think that’s about it for now.  I hope I have killed the camel.  My guess is that if I were to get any replies, they would excoriate me for this wish, as well as some of the other platform-insensitive remarks I’ve made.  (I might even get some brickbats from the PETA folks.)  So be it.  To this I would just say…

What’s in a name?  The description of what it does, no more no less.

This entry was posted in Identifiers, Naming conventions, Variables and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>