Namespace rant

[WDrago]

All,

I don't understand namespaces. Yes, I read the msdn and some online tutorials and although they explain what namespaces are, they don't explain clearly what the benefit of using them is, why I need them, when I need them, and why they're generated automatically.

I have 10 classes in my program and they all have the same preassigned namespace, which is the name of my project. If they're supposed to help organize the code how can they all have the same name? Isn't that like giving every class in your program the same name?

Say I have a class that I want to use in multiple projects, what namespace do I give it?

Everytime I paste a class from one project into another I have to change the namespace and it's getting annoying. How can I avoid this pointless excersize?

What am I missing here? What is the great revelation that I've somehow missed that will make me say, "Oh wow, namespaces! How did I ever live without them?!"

Sorry for the rant, but I hate when I spend a long time reading help files and tutorials and still don't understand the point of something.

Thanks for listening...

-Bill

[deceptikon]

they don't explain clearly what the benefit of using them is, why I need them

Say you have two libraries, each in a separate assembly. Neither use namespaces, but both define a class called Widget. How do you know which Widget is which without some way to categorize them? The answer is namespaces.

when I need them

When there's a potential for name conflicts.

and why they're generated automatically

It's best practice to wrap everything in a namespace at the beginning, if only because it saves you the effort when you invariably discover that it needs to be done later down the road.

Say I have a class that I want to use in multiple projects, what namespace do I give it?

Something that's unique and descriptive. For example, I have a scheduling library for polling services with this structure (company name removed to protect the innocent):

CompanyName.Scheduling
    ScheduleEditor
    ScheduleTimer
    ScheduleTimerPulseEventArgs
    ScheduleOverlord

The namespace ensures that when I want a ScheduleEditor, I can get my company's editor by saying CompanyName.Scheduling.ScheduleEditor. We only have one scheduling library, so there's no need to be more granular than that. But ScheduleEditor isn't such a unique name that another third party library we use certainly won't use it.

Everytime I paste a class from one project into another I have to change the namespace and it's getting annoying. How can I avoid this pointless excersize?

Yes, that does get annoying if you copy and paste code a lot. Honestly, it's either change the namespace or copy the class and using directives separately and leave the IDE generated namespace as-is. It's a minor annoyance though.

What is the great revelation that I've somehow missed that will make me say, "Oh wow, namespaces! How did I ever live without them?!"

Write a large project in C and you'll very quickly learn to love namespaces. The feature doesn't exist, so you're forced to use excessively verbose or cryptic names to ensure uniqueness. ;)

[WDrago]

Thanks for the thoughtful reply, deceptikon.

Okay, so I can have more than one class with the same name as long as they're in different namespaces. I can see the convenience. But in order to do that I'd have to have different namespaces in the same VS project. Is that allowed?

-Bill

[zachattack05]

Yes, different name spaces in one project are allowed. :)

I think of namespaces as a folder tree with each "." defining a new folder. I use them a lot for organizing my code.

[Ketsuekiame]

Yep. Some examples of the ones I use:

Project.Extensions
Project.Utilities.Mathematics
Project.Services

Namespaces are good for organising code :)

[Momerath]

Like Zach said you can think of them as a folder tree, and I actually use a folder tree with the same structure as my namespaces :)

My largest project currently has:

Momerath.Collections
Momerath.Collections.Generic
Momerath.Extensions
Momerath.Numerics
Momerath.Sharith
Momerath.Sharith.Arithmetic
Momerath.Sharith.Math
Momerath.Sharith.Math.MathUtils
Momerath.Sharith.Math.Primes
Momerath.Strings
Momerath.Strings.Search

And I have some other stuff I'm doing that I haven't catigorized yet, but will end up in various namespaces.

[Schol-R-LEA]

One thing that doesn't seem to have been mentioned is that namespaces are less for projects by a single individual, than they are for integrating disparate libraries and projects by different groups of developers. While namespaces are a boon to a single programmer, they are a necessity to developers working with other people's code, where they need to avoid conflicts between programs written without consideration for whether another programmer has used the same class name.

[lolafuertes]

Say I have a class that I want to use in multiple projects, what namespace do I give it?

I would just create a separate project for this class, anc createa separate assembly (.dll)

Then, on each project i'll need it, just adding a reference to the .dll is enoug to fully use it via using statement.

IE, if you create a clas called TheClassToShare inside a project called Wdrago, your default namespace for this class will be Wdrago.

On the project referencing your .dll, you can use your class writing something like

var a = new Wdrago.TheClassToShare();

Hope this helps

[WDrago]

I'm sort of getting all of this and I thank everyone for their replies.

One thing that's still confusing me however, is how every class file in my project can declare the same namespace. It goes against everything I know about programming--you can't have more than one variable with the same name, you can't have more than one class with the same name, so how you can you have more than one namespace with the same name?

Is it that the declaration namespace MyExcellentNameSpace is not really a declaration, but simply a label that says hey, this class is part of MyExcellentNameSpace?

Thanks,
-Bill

[rubberman]

Correct! You can declare a common namespace in many source files / headers. The effect is cumulative in that in each case, the contained classes/symbols are added to that namespace.

[WDrago]

Correct! You can declare a common namespace in many source files / headers. The effect is cumulative in that in each case, the contained classes/symbols are added to that namespace.

Well that explains a lot! Now I totally get it.

I've never seen anything like this in my entire life. Usually when you declare something, that's it, it can never be declared again. It would have been a lot easier for me to understand if namespace declarations were handledlike this:

namespace MyTrigLib
{
    Sine.cs
    Cosine.cs
    Tangent.cs
}

namespace MyHyperbolicTrigLib
{
    Sine.cs
    Cosine.cs
    Tangent.cs
}

Now at least it's clear what files belong to what namespaces and, you have an organized list of all the namespaces and what's in them.

If you've got a few hundred class files and say a dozen or so namespaces how do you know which class is in which namespace without opening each file and reading it?

-Bill

[Ketsuekiame]

If you're using Visual Studio, type the name of the class and hit Control + . This will cause intellisense to lookup the namespace for that class. In the case of ambiguous declarations it will ask which one you want to use (The library containing the class must be referenced by your project).
Similarly in Visual Studio if you have namespace My.Namespace.Is.Here and you type My then Namespace will appear on the list of available declarations and look like: { } Namespace

If you aren't using Visual Studio, you better have a good memory or good documentation :)

[WDrago]

If you aren't using Visual Studio, you better have a good memory or good documentation :)

Right! But as Momerath said, a folder structure could be used to represent the namespace structure.

Well, this issue is resolved. I finally understand namespaces. Thanks to everyone that participated in this disccussion. I really appreciate your help.

Regards,
-Bill

[zachattack05]

In fact, in VS, if you create a folder in the project explorer, and then create a new file in that new folder, it will automatically set the namespace for you to include that folder name. It's quite handy!

[deceptikon]

In fact, in VS, if you create a folder in the project explorer, and then create a new file in that new folder, it will automatically set the namespace for you to include that folder name. It's quite handy!

Except when you don't want it. ;) I like to use VS folders for organization, but don't want the nested namespace. In those cases it's a minor annoyance to make sure I create new files at the top project level and then move them, or change the namespace of files created directly in the folder to be consistent with the rest of the project.

[zachattack05]

This is true.

My logic is that if they are in the same namespace, they need to be in the same folder (or subfolder) otherwise I get confused when looking for the components of a namespace. If I need to know what falls in a given namespace, I just open the explorer and find the folder and bam! That's all that's in the namespace and nothing else.

My mind just works better that way. To each his own!

[Ketsuekiame]

ReSharper actually tries to enforce that rule, but I agree with deceptikon. You may want to section off certain files, but keep them in a parent namespace.

Let's say for example you have a utility that performs some data management. In order to do its job it requires two or three class files, but nothing else in your parent namespace does. So you section it off into its own folder to keep the project structure tidy. There's no point giving it its own namespace, it's only one object, that should sit in the Utilities namespace. there's also not much point in separating the class files into their own namespace. You could but again I don't like doing that.

When you're working in solutions that contain 60+ projects and over 4Gb of code you don't need/want hundreds of namespaces ;)