24

I was wondering, what the purpose of Namespaces in C# and other programming languages is...

As far as I know, they are used for two things:

  • To structure the project into meaningful pieces
  • To distinguish classes with the same name

My Question is: Are there any other things to consider when using namespaces? Do they have an impact on performance or something like that?

Syjin
  • 2,740
  • 1
  • 27
  • 31
  • 2
    They are not used to structure the project, though the namespaces may follow the project structure. – John Saunders May 06 '11 at 17:43
  • @John +1 for the subtle but important clarification. – Yuck May 06 '11 at 17:44
  • 2
    Is it recommended to keep the namespaces in sync with the project structure, or is this just personal preference? – Syjin May 06 '11 at 17:46
  • 5
    Try to make your namespaces follow the *logical* structure of the program rather than the *organizational* structure of the team that built it. If you are producing a library then namespaces should be a help to *users* of the library, not a reflection of the organization of the *creators* of the library. – Eric Lippert May 06 '11 at 18:01
  • 1
    This is **not** a duplicate of the linked question. That question is about **alias'** this is about the usage of namespaces in general. – Liam Jun 19 '17 at 09:35

6 Answers6

49

As far as I know, they are used for two things:

• To structure the project into meaningful pieces

• To distinguish classes with the same name

That's basically it. I would add to your first point that namespaces provide structure larger than just that of the project, since namespaces may span projects and assemblies. I would add to your second point that the primary purpose of namespaces is to add structure to libraries so that it becomes easier to find stuff you need and avoid stuff you do not need. That is, namespaces are there as a convenience for the user of a library, not for the convenience of its creators.

A secondary purpose is to disambiguate name collisions. Name collisions are in practice quite rare. (If the primary purpose of namespaces was to disambiguate collisions then one imagines there would be a lot fewer namespaces in the base class libraries!)

Are there any other things to consider when using namespaces?

Yes. There are numerous aspects to correct usage of namespaces. For example:

  • violating standard naming conventions can cause confusion. In particular, do not name a class the same as its namespace! (See link below for details.)
  • using a namespace can bring extension methods into play that you didn't expect; be careful
  • where precisely the "using" directive goes can subtly change resolution rules in a world where there are name collisions; these situations are rare, but confusing when they arise
  • collisions often arise in contexts where machine-generated code is interacting with human-generated code; be careful in such situations, particularly if you are the one writing the code generator. Be very defensive; you don't know what crazy name collisions the person writing the human-generated half is going to create.

See my articles on this subject for more details:

http://blogs.msdn.com/b/ericlippert/archive/tags/namespaces/

And see also the Framework Design Guidelines for more thoughts on correct and incorrect conventions for namespace usage.

Do they have an impact on performance or something like that?

Almost never. Namespaces are a fiction of the C# language; the underlying type system does not have "namespaces". When you say

using System;
...
class MyException : Exception 
...

there is no class named "Exception". The class name is "System.Exception" -- the name has a period in it. The CLR, reflection, and the C# language all conspire to make you believe that the class is named "Exception" and it is in the namespace "System", but really there is no such beast as a namespace once you get behind the scenes. It's just a convention that you can sometimes omit the "System." from the name "System.Exception".

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • That's very interesting about namespaces in the CLR. I had no idea! – Rob H May 06 '11 at 18:42
  • 2
    This makes me now wonder why there is an »almost« in »almost never a performance impact«. So there are cases? – Joey May 06 '11 at 18:51
  • @Joey: I don't know of any, but there's a first time for everything. One can certainly imagine bizarre cases involving long names, or names that have interesting hash collisions, or whatever. – Eric Lippert May 06 '11 at 20:09
  • 7
    @joey @eric Namespaces are part of the name, so they are part of the assembly, so they are part of the stuff that gets loaded. Namespaces make strings longer, so they make files larger, so they take longer to load and take up more memory. I'm willing to say that Namespace have a performance impact, but I'm also willing to say that the impact is so tiny and insignificant that there is no performance impact. If you're down to measuring impact of namespaces, you may want to stop with .net and rewrite code in straight assembly :-) – Michael Stum May 06 '11 at 20:38
  • I wish I could double vote this. One for the answer and one for the articles. Very useful and straight to the point. – ThunderGr Dec 05 '12 at 08:03
3

According to MSDN a namespace has the following properties:

  • They organize large code projects.
  • They are delimited with the . operator.
  • The using directive means you do not need to specify the name of the namespace for every class.
  • The global namespace is the »root« namespace: global::System will always refer to the .NET Framework namespace System.

Secondly namespace has nothing to do with performance but if you have created your own namespace so you should follow the conventions across the project.

FIre Panda
  • 6,537
  • 2
  • 25
  • 38
2

It doesn't affect performance. But for code readability, I would recommended remove unwanted using statements

santosh singh
  • 27,666
  • 26
  • 83
  • 129
2

Namespaces are a concept pulled from earlier technology, like XML. THe namespace gives context to your classes, allowing you to have say a CUstomer object in your domain and in your data code.

You can also use namespaces to alias, which still does the above, but allows shorter naming for the particular object.

domain.customer versus data.customer

Gregory A Beamer
  • 16,870
  • 3
  • 25
  • 32
  • 3
    The idea of a namespace goes back way farther than XML; the work of Carl Linnaeus in the 18th century comes immediately to mind, though of course he did not call it a "namespace". – Eric Lippert May 06 '11 at 18:04
1

You've touched upon the two main reasons. This is an old article from MSDN but it still applies: Namespace Naming Guidelines

In the Java world the naming practice is to reverse the domain name of the company who owns the product and include the product's name after that. So com.example.product might be a valid namespace, but you don't really see that in .NET so much.

Yuck
  • 49,664
  • 13
  • 105
  • 135
  • In Java that was done to avoid name clashes, but even with plenty of libraries and so on I've yet to see such a thing in .NET. Maybe Java was designed for projects with a few billion source files and millions of dependencies ... who knows. – Joey May 06 '11 at 17:47
  • 3
    The modern link is [Names of Namespaces](http://msdn.microsoft.com/en-us/library/ms229026.aspx) – John Saunders May 06 '11 at 17:47
  • @Joey: I suspect the people in the Java world who started using that pattern thought there would be conflicts otherwise. – John Saunders May 06 '11 at 17:48
0

Those are the big ones right there.

There aren't really performance benefits. At least, not directly. without namespaces framework would have to search the a lot more places to find the code you are trying to include - It would almost be like needing to load up the ENTIRE .NET framework for every project. Well, not really, but its close enough for this discussion.

Jeff
  • 13,943
  • 11
  • 55
  • 103
  • they won't, actually if you try to reverse engineer a C# program, you won't see any using directives they instead use the fully qualified type names – jalsh Feb 21 '18 at 12:28