On Naming

latest-small-64So, why “Kev on Software”? As you can imagine the first bit is easy – my name is Kevin, but why “on Software”. Back way back when there was a blog called “Joel on Software” – by Joel Spolsky. He wrote passionately about what made good and bad software, and where he saw the pitfalls. It’s been many years since I’ve been regular reader but most of his opinion pieces stick with me, even if I didn’t agree. I think thats what his blog taught me most, that thinking for yourself is the key to everything, especially in software. Guidelines, methodologies, courses and approaches are all great, but if you stop thinking for yourself you’ve already set up to fail.

As I was thinking about the name, it occurred to me I care about naming in software more generally. When you’re building code, or documentation or even marketing material the names you use mean everything. The right name makes something instantly memorable, the wrong name can be useless or in the worst case mislead. Consider the following:

I have an object that contains a set of Book objects. If thats it’s only description in your system, then BookList makes a perfectly good name. However, where in your system is a collection of books meaning really only a collection of books?

Is it a Shelf? Is it a Catalog? Is it a Library? Does it really matter? Well yes, it can do and this is where the thinking for yourself bit comes in.

  • Who is reading this code, is it only ever you or are there other people maintaining it?
  • Does the context mean it doesn’t have all the properties of a list, e.g. can you add and remove items? (Yes, you could for for ReadOnlyBookList, but now its getting silly)
  • How long is this code going to last, does the design of the interface to this class really matter at this stage?

Reading the above you’re probably saying, but you’re not arguing either way, and that’s correct. Think for yourself!

If the code isn’t going to last more than a day, who cares what it’s called? Why waste perfectly good cycles on a name that will disappear shortly. That said, are you sure it’s only going to last that long – and are you willing to put the time into change it (and it’s ripples across the code base) if the code does end up lasting longer?

Is the addition of methods in the interface for a BookList going to imply something outside of the context of the class? Is removing items from the list possible in the context, and if not, is having the method going to mislead and confuse?

Are you the only one who is ever going to maintain this code? In which case does it really matter given you’re going to keep the whole thing in your head anyway? Are you sure?

The above questions, and many others, sound like a lot of thinking to do as you’re endeavouring to code away as quickly as possible. However, once you’re thinking about it every day as you code, it’s split second decision making – that you don’t need to cross check with every guy around you and his dog.

You think, then act. If a discussion does arise later then you know why you made the decision and if things have changed you refactor.


Tags :
Categories : Motivation Reason Software

Leave a comment