Naming things is only hard if you are trying to be consistent across a large systems, or hoping that names will replace documentation and assumptions.

If you are going to ban names, I nominate the entire index of the GoF book: Factory, Singleton, Command, Proxy, etc. all sort of convey an idea of the kind of stuff they probably do, but nothing truly precise about the details.

Or I can just accept a rough meaning of the word, name my classes / modules / variables / etc reasonably and then rely on a coherent approach to design and documentation to provide with the details.

- XXXManager: owns the lifetime of objects of class XXX and the relationships between them.

- XXXHandler: responds to events relating to XXX.

- XXXFactory: creates instances of the polymorphic type XXX

- etc.

There are only 2 hard problems in computer science, caching, and naming things, and off by one errors

Unambiguous syntax is also a hard problem, it now appears.

More meaningless words:

- system. Everything is a system.

- data. Everything that isn't executable is data.

The class name modifier that irks me is "Base", as in BaseWidget or ConnectionBase. Just call them a Widget or Connection! :)

BaseWidget is useful when it's an abstract class, to differentiate it from the actual implementations WidgetA and WidgetB.

Wouldn't a "Widget" abstract class name also be differentiated from "WidgetA" and "WidgetB" implementations? Then APIs could take parameters of type Widget instead of type BaseWidget. "Widget" is a shorter, cleaner name and avoids documenting implementation details like names such as "BaseWidget" or "AbstractWidget".

Usually, I want to make the name of my interface the cleanest possible name. In that case, my interface would be named "Widget". Then, if it makes sense, I might have a partial implementation that works for many cases - I would probably call that WidgetBase. Actual implementations of the widget would try to have a name related to what makes them different than the others - maybe Button, TextBox, etc. Those implementations might inherit from WidgetBase if it makes sense, or just implement the interface. At any rate, WidgetBase is only ever referenced by subclasses - the users of the widget code would either depend on "Button" or "TextBox" specficially, or the "Widget" interface for more generic handling. WidgetBase is really just there for convenience, and you could remove it if it turns out not to be as useful as you thought.

Java frameworks use a similar pattern with a "Widget" interface and an "AbstractWidget" partial implementation.

There are certain ... linguistic... reasons why Base appears in class names. It's important to understand the subtlety. In certain languages, especially those with packages or namespaces, you'll likely have a namespace Foo::Bar::Widgets where you put your WhateverWidgetWhatever classes. The package foo.bar.widgets.widget, or namespace Foo::Bar::Widgets::Widget, can look weird to some; it's also longer / less predictable, so you could potentially see them simply be called Foo::Bar::Widget::Base, which avoids naming duplication, and allows developers to not have to worry about plural/singular names.

From the Android SDK :)

http://developer.android.com/reference/android/os/Handler.ht...

Man, as much as I like the idea of Android, the SDK trips me up so often!

I personally don't like "Helper". Shouldn't every class be helpful?