I don't have too much of a problem with "er" suffixes. It doesn't make it too verb-like, IMO. A SpellChecker class could have a CheckSpelling method that as the verb. The namespace in which the class resides could be SpellChecking; making a clear delineation between namespace, class, and behaviour.

I generally use the "Serivce" prefix when dealing with classes that don't have state or don't have both attributes and behaviour. Many things that are encompassed by the service pattern aren't real objects and thus sometimes don't have a clean noun name. The problem with some service implementations is they are a catch-all for functionality that needs to occur but doesn't fit on a specific entity object--making naming it very difficult. Functionality that deals with Order objects, for example, what do you call such a service class? Usually the logic is very disparate and "OrderService" is the only sensible name.

You could use "Utility" or "Manager"; but those aren't as intention-revealing as "Service". "Service" is a defined pattern and it makes it more clear what it's members are intended for.

In the more general case of not using pattern names in the the class name; I do agree. The class name should describe the object; not it's implementation.

I see no issue with the -er either. It's the nature of the English language. Switching to the -ingService isn't much difference. You've substituted a gerund for a noun and have not added anything to the intent of the class.

The argument against -er or Manager or Service is semantic in my experience. If a developer can't tell what the intent of a class named SpellChecker is, changing it to SpellCheckingService isn't going to save him/her.

I'm leaning more to using "Service" in the class name this week, but that's probably because I just finished the chapter on it in Domain Driven Design :)

Putting the pattern name in the class names has been helpful on our team, but that might be because we're still transitioning away from the "put a bunch of related functions together and call it a class" stage - it helps us make decisions about our design choices. Time will tell if it's a training wheels thing or a long term mechanism.

"No more 'er' ending, but it does start to encroach on another naming guideline that I have: don't use pattern names in class names.

In the end we want the class names to be intention revealing. "

Uhm, wouldn't using a pattern name in the class be a good revelation of intention?

In fairness, I can see why you would not want the pattern in the class b/c of implementation worries. However in some cases I think the behavior is pretty obvious and if your underlying architecture is going to change that much I'd almost think the class name should as well.

I tend to think -er is fine. Some people use the Utility suffix (as in SpellCheckUtility or SpellCheckUtil).

I am not bound on any of them. I tend to lean towards Service though. Or -er. Or Utility. ;D

PS. Is it bad that "SpellCheckUtility" failed the spell check on this blog?

I too am very interested in naming conventions, I even used your blog entry to start a discussion over my my site as well. The bigger issue of naming can be very religious.

I could see using that as a warning sign that maybe the class is doing the wrong thing but honestly if it is a parser then name it a parser. Whatever reveals the intention of the class is the right name

Classes ending in 'er' aren't all bad. 'Helper' classes used as general utility containers is probably a case of where 'er' should be avoided, but then again maybe you need a 'Helper' class. Today I'm working with a mess of 'Mapper' classes. :)