Providing context in Class name, even though the namespace provides context

Question

So I am reading Clean Code and I want to write my class names with the proper amount of context, but how does .NET namespaces play into the concept of Meaningful Names?

Do I forego context in the class name that has been provided in the namespace?

For example, If I have the following namespaces

MySolution.Event.Registration.BeginRequest 
MySolution.Event.Registration.EndRequest 
MySolution.Event.Registration.Error

Should I name the classes EventRegistrationBeginRequest, etc.?

• Machado: Related reading: .Net Framework Naming Guidelines.
• amon: Will the namespace context be visible in code that uses these classes? E.g. do you expect to always see MySolution.Event.Registration.BeginRequest, or would users import that class name and write BeginRequest? In my experience, it's usually the latter – thus indicating that each class name should provide enough context in isolation.

Answer 1

Avoid classes with identical names, even if the name spaces differ.

The problem is, you import and forget about the namespaces and it becomes unclear which class is meant to be used.

Refactoring can be a nightmare of you move the class to a different project.

I would also not recommend the 'clean coding' BigLongClassNameOfDeath either. Try and keep your names specific to your functionality, avoid public Request, Response, Error etc, or at least move them to a common library