Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.?
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
MySolution.Event.Registration.BeginRequest, or would users import that class name and writeBeginRequest? In my experience, it's usually the latter – thus indicating that each class name should provide enough context in isolation. – amon May 5 '17 at 7:17