An awkward, open question, but it's a problem I'm always bumping against:
Software that's easy to maintain and work with is software designed well. Trying to make a design intuitive means naming your components in such a way that the next developer should be able to infer the function of the component. This is why we don't name our classes "Type1", "Type2", etc.
When you're modelling a real-world concept (e.g. customer) this is generally as simple as naming your type after the real-world concept being modelled. But when you're building abstract things, which are more system-oriented, it's very easy to run out of names which are both easy to read and simple to digest.
It gets worse (for me) when trying to name families of types, with a base-type or interface which describes what the components have to do, but not how they work. This naturally leads to each derived type trying to describe the flavour of the implementation (e.g. IDataConnection and SqlConnection in the .NET Framework), but how do you express something complicated like "works by reflection and looking for a specific set of attributes"?
Then, when you've finally picked a name for the type you think describes what it's trying to do, your colleague asks "WTF does this DomainSecurityMetadataProvider actually do?"
Are there any good techniques for choosing a well-meaning name for a component, or how to build a family of components without getting muddled names?
Are there any simple tests that I can apply to a name to get a better feel for whether the name is "good", and should be more intuitive to others?
Best Answer
For naming, there are six techniques that were proven to work for me:
PS. In case if your API is going to be public, above applies before that - because, you know,