In Defense of the _Underscore

There it sits near the top of your keyboard, just to the right of the zero and to the left of the plus sign.  In the last year of my professional life, that one innocuous character, the older brother of the hyphen, has sparked more debate among my peers than any other development practice.

I am a proponent of the underscore.  There, I said it.  The use of the underscore is a polarizing topic in most software development circles, with both sides often citing arbitrary arguments for or against its use.  I, personally, have finally had enough.  Today, I am presenting my defense of the underscore in a public forum and oficially inviting you, the reader, to reply with your argument for or against its use.  The only thing that I ask is that you be objective (I don’t want to hear “it’s ugly”, “you shouldn’t do it” or “it’s bad practice”) and that you present it here, publicly, for all to read.

As with any development convention, I only use the underscore under a very specific set of conditions.  As a matter of fact, I only use it under two very specific conditions: prefixed to a private member variable or postfixed to a function argument.  But, why do I use it?  Do I use it because I think that it looks nice?  No.  Do I use it because other people use it?  No.  This is why I use it:

  • By prefixing all private member variables with underscores, you are automatically creating a valuable shortcut.  Now, whenever you enter the underscore character anywhere within the class, Intellisense will automatically provide you with a list of all private member variables within scope.  Tell me that’s a bad thing.
  • A quick review of the class reveals all function arguments and private member variables.  While reading a block of code, I can quickly identify the nature of any variable without having to use the tooltip.  Why is this important?  Being able to quickly identify the nature of these variables makes code, in my opinion, more readable and easier to debug.  I can already hear you crying, “Well, if you’re going that far, why don’t you just use Hungarian notation?”  With Hungarian notation, I have to decode the first three characters of each variable to glean its type.  Since this notation seems to vary in convention from developer to developer, it tends to make code less readable.  The underscore doesn’t attempt to share this much information, making it simpler and less ambiguous.
  • Although the introduction of automatic properties in C# 3.0 has certainly made life easier, there are still times when traditional properties are necessary.  More often than not, these traditional properties implement some type of private backing variable.  Naturally, this backing variable typically shares the same name with the property itself.  Since C# is case-sensitive, technically this doesn’t present a problem.  However,  if you slip up and don’t enter the name of the backing variable or property using the exact casing, Intellisense will guess for you and it doesn’t always guess correctly.  This can cause a compile-time error, or, more likely, a more painful runtime error.  Yes, I know, you can always give the member variable a different name, but this often forces you to come up with an arbitrary name in order to compile, making your code even less readable.  By prefixing the backing variable with an underscore, you can kill two birds with one stone.  I find this to be a rather graceful solution in most cases.

Now, it’s your turn.  Do you agree with me?  Fantastic.  Do you disagree with me?  Fair enough.  Tell me why you disagree with me.  Remember, be objective.  Don’t tell me that it’s ugly and don’t tell me that it’s bad practice without justifying your position.  If you do, however, have a valid, objective argument against its use, please share.

About this entry

You're currently reading “In Defense of the _Underscore,” an entry on casey.in.point

Published:
06.28.09 / 12pm
Category:
Uncategorized