Smelly class names?

Question

In your experience, what are some "smelly" keywords in class or function names that might be warning signs of bad object-oriented design?

I've found that classes containing the word Manager or Base are often suspect. For example, a FooManger often indicates poor encapsulation or a singleton design that is difficult to reuse.

A FooBase class is typically an abstract base class that is never expected to be directly referenced in caller code. It's only used to share some code implementation without a true IS-A relationship. And the Base class name exposes internal implementation details and does not reflect a "real world" object in a Domain Model.

Functions that include the word And or Or (e.g. DoThisAndThat() or DoThisOrThat()) are smelly. The function is probably lack cohesion and is trying to do too much. And the name exposes internal implementation details.

Answer 1

I don't agree with you on the Base point. For example, in ASP.NET (both WebForms and MVC) it is not at all uncommon with base classes for a lot of different things - the most common use I've seen is for methods that you want to run every time a page is loaded, or every time a specific group of pages are loaded. You then create a PageBase class that inherits from System.Web.UI.Page, containing the method you want to copy, and make all the pages you want to run this method inherit your PageBase instead of the default System.Web.UI.Page. This isn't necessarily poor design - it is one of many tools to try to follow the DRY principle ("Don't Repeat Yourself).

Answer 2

To quote Roedy Green's How To Write Unmaintainable Code:

Be Abstract

In naming functions and variables, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and doargs_method.

Answer 3

Util classes can be quite useful, but if the name if plain "Util" or "Utils" it's rather undescriptive.

Answer 4

The worst function name I've come across in real life:

DoTheLogic();

Answer 5

how about a "cls" prefix or a "Class" suffix? Those smell

Answer 6

The word "Stuff" in any sort of class/function name is going to be a very bad sign (provided it's not the verb form). DoStuff(), ValidateStuff(), FetchStuffFromDatabase(), pick your poison.

Answer 7

The most common 'smell' I've found is confusion of concepts of number. You don't want a class called Contacts if one instance refers to one "contact". You call it Contact instead.

Answer 8

DoThisAndThat() or DoThisOrThat() inherently violate the Single Responsibility Principal. A method should do one thing and one thing only (even if that one thing is calling a bunch of other methods)

Answer 9

I've found this to be helpful:

"Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb."

(From Clean Code by Robert Martin, p25)

Answer 10

I think anything that starts with class foo is likely to be unreadable.

Yes, I mean that literally. I tend to over-use "foo"...

Answer 11

Class names are largely arbitrary, so pick what works for you and the consumers of your code. But some kinds of class names can be indicative of a larger problem.

To illustrate a point:

ClassName
  LongClassName
    VeryLongClassName
      VeryLongClassNameThatIsIndicativeOfExcessiveUseOfInheritance
      VeryLongClassNameThatIsNotIndicativeOfExcessiveUseOfInheritance
    SomewhatLongClassName
  ShortClassName
    ShortNameOfVeryLargeClass
    ShortClassNameThatAlsoHasTheWordShortInTheName

Don't worry so much about the names. Worry about the design. Where I work, we routinely bandy about classes with names like F, P, V, and $, and it's not a problem for anyone.

Answer 12

I don't agree with "Manager", and apparently neither does Microsoft (not that they are always right!) Consider the ConfigurationManager class. It's a legitimate use of "Manager" because this class manages the app.config/web.config files. "ConfigurationReaderWriter" would be bizzare, and having two classes (ConfigurationReader and ConfigurationWriter) wouldn't make much sense.

Answer 13

Singleton.

Answer 14

The words "Data", "Info", "Struct", "Record", etc. in a class name mean that somebody has Not Been Thinking. Ohhhhh, that's the class with the DATA in it! So all these other classes, they don't have any?...

(Yeah, I know, interfaces. But even then, naming the implementation of an interface "InterfaceData" would be pretty dim.)

Answer 15

Class names that aren't indicative of what they do. There's a lot of things just called 'Manager' or 'Interface' hidden inside libraries that I've worked on in the past. You're never supposed to call them directly as they're internal structures to manage its functions.

It's not clear what 'Interface' interfaces to; is it a programming interface, does it interface on the network or to hardware? To find out you have to go and read the code/docs for the Interface class.

Of course when I say 'interface' I mean any reasonably vague single word name.

Answer 16

" *Helper* ". If a class can't do its job, who can?

Answer 17

I've seen interfaces called InterfaceNameImpl. What can be worse?

Answer 18

http://stackoverflow.com/questions/560648/object-oriented-login-functionality/563392#563392

A Manager is in charge of many directly related entities. The manager is responsible for how those entities interact with a client. Some manager classes do not have well defined names such as array, stack, and queue.

Answer 19

If a class can't have a more specific name than FooManager, then it's possibly trying to do too many different things with Foo.

Answer 20

Manager, Handler, Thing, Dingus, Doodad, Entity, Gizmo, Object, Helper, Widget, Gadget

-> http://journal.stuffwithstuff.com/2009/06/05/naming-things-in-code/

Answer 21

Naming all depends on the context in the application it is used in. There are no hard and fast rules.

If your comming into a project that's already up and running and they are using verbs for class names everywhere, why would you confuse programmers down the line and take a different naming approach?

Think about the big picture.

Answer 22

My biggest pet peeve is one that I've run into a lot on a large real-life project: Helper. Sometimes it's a bunch of static utility methods, sometimes it's actually a strategy object, usually it's just a blob of code with no well-considered place in the design.

Also, Strategy is a bad sign, much like Singleton as MSN noted. Congratulations! You're using a design pattern!

I never liked Util for utility classes, but that's more a matter of taste. (I prefer the pluralized noun, like Arrays or Collections from the JDK, for a bunch of static methods related to one kind of object.)