What's in a name?

Recently I've found myself spending a lot of time discussing naming. I've come to realize that this is an area that has not received enough focus in software design. I'm not primarly talking about naming conventions, i.e. should things use camelCase, PascalCase, begin with underscore etc. It's about names of classes, namespaces, methods, properties, variables, modules, programs etc.

As a horrible example how bad it can get, I recently read an article in MSDN magazine about Windows Installer XML, WiX. Can you believe this leading software company names the components of WiX as follows:

Candle
Dark
Light
Lit
Tallow
WixCop

Just how does this naming help you work with WiX? I'm sure there's a funny story behind it, or someone just ran out of imagination. All these things add upp, and every time you can't recall what a thing does or what it's name is it causes frustration and delays. Here's a suggested alternative naming of the same components:

Wix2XMLInt
Msi2Wix
XMLInt2Msi
WixLibGen
FileTreeWixGen
WixCop

Given the following descriptions, which do you think are easiest to work with?

Candle - Transform WiX source to intermediate XML
Dark - Generate WiX source from a MSI file
Light - Transform intermediate XLM to a MSI file
Lit - Generate WiX libraries
Tallow - Generate WiX source to replicate a directory/file tree
WixCop - Check a WiX source for potential problems

Most people will have trouble remembering or associating something if there's no mnemonic or association to what it is or are. If you call something 'red', that is in fact 'blue' - this will cause a problem for people!

Do spend some more time thinking about how you name things!

It's a one time issue, but the names live on forever. How many names of things do you work with daily? I probably keep at least a 1,000 in my head at any one time. Those that cause me difficulty are those that I can't find any thing to associate with - because they are meaningless in the usage context, or associate the wrong way.

Planned exceptions considered harmful, or try the Try-pattern

A really common misuse of exceptions in code is to validate input. A typical code pattern may look something like this:

private int GetIntValue(string s)

{

int i;

try

{

i = int.Parse(s);

}

catch (Exception)

{

i = -1;

}

return i;

}

This is bad. Very bad. The exception is not an exception, it's an expected outcome of validating the input. That is not the way of doing this. Enter the TryXXX pattern, implemented in various parts of the .NET Framework 2.0 and later, and hopefully soon in your code! It should look like this:

private int GetIntValue2(string s)

{

int i;

if (int.TryParse(s, out i))

{

return i;

}

return -1;

}

The TryXXX pattern is a very nice way to handle the situation that you're expecting, and want to handle, bad input. In your own implementation, you should not just wrap a try-catch block with the TryXXX pattern, you should ensure that your data is valid without generating an exception in the first place.

If other parts of the code is not expecting any invalid input, and the right thing to do indeed is to throw an exception, then it's the TryXXX that should be wrapped, and if it fails throw the exception.