If you can't think of a good name, use a bad one

I’ve just read a great tweet from @KentBeck that provides an interesting solution for something that I have always struggled with.

if you don’t have a good name for it, give it a bad name. a really, really bad name so you’ll fix it later.

Good naming is hard

Sometimes when writing a class, or occasionally even a method, I struggle to find a good name for it. After a while I give up trying to find a good name for it and chose something that is just about “OK”, a working title if you like. Unfortunately this tends to create poor generic names, such as “ConnectionManager”, that vaguely make sense, but can obfuscate the true purpose of the class. I’ve lost count of the number of times that I’ve heard developers say something like, “Oh, so that’s what that class does!”

The problem with these “OK” names is that they tend to have a strong inertia to change. Typically I have the intention of going back and renaming it, however the longer I leave it the less likely this is. If the name is adequate, but not great, then why go through the effort of renaming it? Sure, some IDEs, such as Eclipse, do a superb job at refactoring, however a lot of the code we write here at Caplin is in JavaScript and the tool support for this isn’t as good. Regardless of this, even where there is good tool support, there are time pressures, backward compatibility and other considerations that lead to “OK” names sticking.

Overcoming renaming inertia

This brings me back to Kent Beck’s excellent suggestion. If you provide something with a really bad name the inertia to change it will be non-existent. You will have to change it before it becomes part of your public API or other developers have to use it.

The great thing with this is that it allows you to write your class and see what it responsibilities are before you provide its proper name. This should lead to meaningful names that define exactly what a class does, ensuring no one is surprised when they try to use it.