3

I can't see how having a namespace for each folder makes sense. As near as I can tell, the point of having namespaces is to avoid name conflicts. But, Microsoft, in their namespace naming conventions, says:

❌ DO NOT give the same name to types in namespaces within a single application model. For example, do not add a type named Page to the System.Web.UI.Adapters namespace, because the System.Web.UI namespace already contains a type named Page.

If you're going to follow that recommendation, what is even the point of having more than once namespace per project? Let alone having a new namespace for every folder in a project?

Improve this question
5
  • The question asked by the title is a bit different than the question asked in the body. The title question is unanswerable, but the body question is not and is on topic here. I edited and flagged for re-opening
    – mmathis
    CommentedMar 31, 2022 at 15:33
  • @mmathis That's a fair point, and a good edit, I accepted it.
    – Josiah_Maddux
    CommentedMar 31, 2022 at 15:47
  • 1
    Note that these guidelines are for developing class libraries like the .net BCL, not necessarily for application code. An "application model" roughly means a framework like windows forms, WPF, asp.net etc.
    – JacquesB
    CommentedMar 31, 2022 at 18:18
  • 1
    I agree with @JacquesB. The quote is taken out of context; it’s a framework design guideline and only applicable within the context of ‘application models’. Bricelam explains here what Microsoft’s definition for application model is.
    – Rik D
    CommentedMar 31, 2022 at 20:20
  • 1
    While namespaces do help avoid naming conflicts, you can use them for more than that - they are a tool to organize code and can serve to indicate large-grained logical components and/or layers, or otherwise separate code that's at different levels of abstraction. As for why VS automatically matches namespaces with the folder stricture, I would guess that this comes from the way Java does things (C# was initially rather similar to Java, and borrowed many ideas from it). Unlike Java, though, C# and VS do not enforce this.
    – Filip Milovanović
    CommentedMar 31, 2022 at 21:02

3 Answers 3

Reset to default
8

The whole point of a namespace is that type names within the namespace are unique. So this is okay:

namespace A { class Foo { } } namespace B { class Foo { } }

This allows you to instantiate two different types of Foo from two different namespaces, and this is the right way to do it.

The guidance you are questioning refers to a specific type of situation, illustrated by this example:

namespace A { class Foo { } } namespace A.B { class Foo { } }

In this case, you have two types named Foo that are in different namespaces, but the namespaces are nested. Because type names are resolved by walking the namespace, you can end up with ambiguity.

For example, what do you think happens when you do this?

namespace A { using A.B; public class Program { public static void Main() { var foo = new Foo(); Console.WriteLine(foo.GetType().FullName); } } }

You might expect the output to be A.B.Foo, but in fact it is A.Foo. Confused? That's why we don't do this.

Improve this answer
    2

    The guidelines you quote are for developing class libraries like the .net BCL. An "application model" roughly means a framework like Windows Forms, WPF, asp.net etc.

    So you shouldn't have more than one class with the same name in the same framework, even if they are in separate namespaces. This is because it makes it inconvenient for the consumer of the framework, i.e. someone writing code which use the framework or library. It is common to import multiple namespaces from the same framework in the same file - but if the same name exists in multiple imported namespaces it becomes ambiguous.

    On other hand, it is not a problem to have the same name (like Page or Button) in multiple separate frameworks (like WPF and MVC) because it would be very unlikely that anyone would import from both frameworks in the same file.

    Improve this answer
      0

      As a project gets bigger you want to segment its features just like you want to segment anything as it gets bigger. In order to find anything rapidly you need levels that identify domains. Whether in geography, a company or a store, you order from course to detailed.

      If your project is not a world scale project you may well get by with a single namespace but then you would not need any folders either.

      Software projects are file based, they are "physically" ordered in folders and files because they have to be. They are logically ordered in namespaces because it is convenient. It makes sense to align these orderings to make it easier on the head. You will only have to learn one ordering and you will not get confused.

      Improve this answer

        Start asking to get answers

        Find the answer to your question by asking.

        Ask question

        Explore related questions

        See similar questions with these tags.