I often struggle with deciding how to name a class. Not so much because the class's purpose is unclear, but because of names like xxx***Controller***, xxx***Manager***, xxx***Info***, xxx***Helper***, xxx***Util*** etc that I see everywhere.
If I have a class that uploads some stuff over HTTP, I tend to name it HttpUploader or something on those lines. I have seen many instances where a similar class being named HttpUploadManager, HttpTransmissionController, HttpUploadHelper and so on.
I am sort of confused as to when to use Controller, Manager, Info etc. Is there any article or book that can help me become a better namer of classes?
PS: Also, a name like HttpSender sounds pretty anemic when compared to HttpTransmissionController or HttpDispatchManager :P
The popular opinion on SO seems to be to avoid the use of suffixes like Manager, Info, Helper, or Util.
See: Smelly Class Names and Class names that need refactoring.
You could try looking at a list of more descriptive (colorful?) suffixes too: ManagerManager.
The problem with the usual advice (name the class for what it does) is that many of the things a class does have no good real-world equivalent, and so our traditional vocabulary may not match well. For example, an HttpUploader may be paired with another class that helps with the uploading, doing some coordinating, or (dare I say it?) manages the uploading. This sort of middleman coordination is common in software, but the words to describe it are all so vague that they invite scorn.
If you are having difficulty selecting a name, you could consult the ClassNamer.
The book Clean Code has a full chapter on variable names. Good stuff.
Naming is hard, so don't worry that you struggle, because we all do. And trust me, it never gets any easier!
Personally with the whole Controller/Manager/Helper/Util/Whatever suffix thing I tend to use the rule that if it's a convention (e.g. for an ASP.NET MVC it's convention that the controller class name ends in "Controller") then use the suffix, otherwise try like hell to avoid it. I'd much rather have a class called
HttpUploader
thanHttpUploadManager
.The most important thing about naming, is that the class should do what it says. If it is a class that uploads something using HTTP then
HttpUploader
describes it exactly. Using a fancy name likeHttpUploadManager
doesn't tell me what it does. Does it upload the thing itself? Does it manage the upload of multiple things? I like to keep things as simple as possible, while describing the purpose of the class/method/whatever.A good guideline I find is that if you're really struggling to name something, like you've spend ages thinking and you still can't distill what it does into a reasonable name, then you probably need to refactor whatever you're trying to name into smaller, more specific components.