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.

2 thoughts on “If you can't think of a good name, use a bad one”

  1. Great post. There’s a whole chapter in the Robert Martin’s “Clean Code” book on meaningful names. Names should evolve as the code changes and improves, and provided you use tools like Eclipse, refactoring names should be easy and help, not hinder developers.

    1. Thanks Steve,
      I found Clean Code an excellent book and frequently revisit it for inspiration. Tools like certainly Eclipse do make refactoring names easier, and I would encourage any developer to make use of them.
      The main concern I have is when you are providing an API, where changes to names can introduce backwards compatibility issues, a topic that I have previously gone into some depth of (http://blog.caplin.com/2010/02/02/agile-framework-development/). Again Kent Beck has provided some very useful insights into that topic too in his book “Implementation Patterns”.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *