When working within a single project that contains multiple namespaces, should these namespaces be treated as boundaries? Or is it acceptable that any namespace can access any other namespace?

For example, say I have the following namespaces in a project called Physics

  • Physics.Models
  • Physics.Math

Say in this case that some Models use classes defined in Math, and Math uses classes defined in Models. Is this an acceptable solution? Does there need to be some hierarchy to the namespace names that indicates dependencies? Something like

  • Physics.Math
  • Physics.Math.Models

Are there rules that should be followed? Or is this just left up to the developer to make smart and pragmatic decisions about relationships within a single project?

  • 1
    Try to keep the dependencies acyclic as you can, so more like layering than mutual dependences. However, this is often not possible for foundational concepts, so don't sweat it.
    – Erik Eidt
    Commented Aug 15, 2018 at 22:07

1 Answer 1


The short answer is that no there are no rules and its up to the developer as shows by the fact that the language itself doesnt care how you go about dealing with namespaces.

That being said, the way that you split up your namespaces, if you use them at all, falls down to the way the rest of your project is divided and what you(and your team) decide is the best way to address it. For your example, I would personally go with your first approach becasue it better communicates the use of the items in the namespace, but that is to me and may well not be the way someone else sees the namespace nomenclature.

tl;dr No, the language doesn't care, and it's a stylistic choice you'll have to make yourself

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.