Class naming chaos

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.

If you are having difficulty selecting a name, you could consult ClassNamer.org.

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 than HttpUploadManager.

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 like HttpUploadManager 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.

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.