Naming classes becomes debilitating

Question

I'm not sure if this is an OCD trait or not, but I find that sometimes I get completely blocked unable to continue what I am doing when naming a class (or function, or namespace etc) that I believe is to be used outside of a given project. An API for example. Or a utility class library.

If the naming isn't exactly right (in my mind) I just can't continue...I get stuck trying to come up with the right name. I've tried writing little apps that would use it to see what the names look like but that doesn't seem to help...

I know it shouldn't matter, and it's against any programming mindset to assume you'd get it perfect first go...I just feel powerless to it...

Any tips/ideas would be greatly appreciated...

Answer 1

To my mind the problem you have is not just finding a better way to come up with good names, but dealing with the compulsion to do so. If I'm honest, I recognise a similar trait in myself. Names are important, after all, and I do like a good name for the concepts I'm working on. However, they are not always the most important thing.

Here are some of the methods I use to overcome this kind of thing:

1. Recognise that there is no perfect solution, only solutions that are better than others.
2. Put first things first. It is more important to complete a programming assignment than to do it perfectly.
3. Ask other people. We all have our areas where we bog down, but fortunately different people bog down in different places. Perhaps someone else will come up with a good name, or tell you that it really doesn't matter.
4. Set a time limit. Give yourself x minutes to do the thing you get hung up on, then move on.
5. Promise yourself that you'll come back later. Keep a log of things you want to come back to. Lots of these kinds of problems become clearer when you leave them alone for a bit. Either you'll come up with a better name later, or you'll recognise that it really doesn't matter.
6. Recognise that in 100 years time, nobody will care anyway.
7. Do the opposite. Give a class a really bad name, and see what happens. This will either confirm the need to spend time on better names, or show you how little it really matters. Also, this will help you break out of the obsessive mind set.
8. Pray. This often works for me.
9. Value yourself apart from what you do. Break away from the idea that your own value comes from delivering perfection. When we recognise that we have intrinsic worth, quite apart from our jobs, we feel less shame when we don't measure up to our own standards.
10. Make up new words and use them to name your classes, or just re-purpose old ones. Programming is a creative process, and sometimes the ideas we capture are new ideas. New ideas need new names. "EmployeeTransmogrifier" is a perfectly valid name for a class.
11. Consider that you're trying to solve the wrong problem. For example, it isn't a good idea to write an API without a very clear idea of what the caller's needs are. If you solve this problem, your naming problem might be a lot easier.
12. Have lunch. Lunch is always good.

Answer 2

Firstly

Ask yourself the question "what is this class's single purpose?". Without adhering to Single Responsibility Principle, naming classes and methods becomes very difficult. If you can't answer that question, you may need to re-think what you want the class to do, and consider separating the concerns. This will make it easier to name

Secondly

Do you have a pattern for how you name your classes? Perhaps try looking at some common naming patterns, for example the pattern, which becomes a lot easier to follow once you've addressed SRP above. Does your class parse XML? Try XMLParser. Does it parse XML, create domain models to represent the input, persist them to the DB and then post a success message to Twitter? Try refactoring.

Thirdly

I understand where you're coming from, and have been in a similar situation before. Perhaps try fleshing out your class with some functionality, with a temporary name to begin with. With any good IDE or refactoring assitant, renaming the class should be a one-click action, so what you name your class initially doesn't need to be permanent! This will both help you get past your OCD-block, and give your subconscious time to process it a bit further.

---

Finally and slightly off topic

I had a lightbulb moment in some work I was doing the other day, implementing a non-critical system, and I was spending a fair time playing around with different namings of classes etc... Name your interfaces according to the functionality, name your classes according to their specific implemntation... For example, you might be tempted to have IXMLParser and XMLParser, but what happens when your input changes to JSON? Try IInputParser instead, that way you can create concrete classes XMLParser and JSONParser which both implement IInputParser in different ways.

Answer 3

For me it's usually a sign the design is not clear in my mind, so I make up a name, and give myself a time (say 2 minutes) to come up with a better one, at the end of that time, I have to use the one I came up with first. Barney, Wilma and Fred are favorites to start with. I do things like "BarniesInputParser" The names are so bad I have to come up with a better one or change them later. They are also so bad they are unique, making refactoring trivial and safe, and anyone looking at the incomplete code can see instantaneously it's incomplete.

The important thing is that while you are not adding functionality, you aren't giving your brain any new information to use to define the name (and clarify the design). All you are doing is regurgitating the same input in different ways.

Or go make a coffee. Before you get to the machine you will have it...

Answer 4

I got this from a friend awhile back. Write out what your process is supposed to do. Just a short narrative. Then take the nouns and turn them into classes, the verbs into methods, and the adverbs into properties.