Jon Galloway recently pointed out something that's been bothering me for a while:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/01/a-modest-namespace-proposal.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/01/a-modest-namespace-proposal.html
The problem I see is that MhtBuilder isn’t exactly a great classname.
Fine, but CodingHorror.MhtBuilder (or whatever) doesn’t make it any better. The root problem as you correctly point out, is to give your classes good names. Blindly adding a namespace doesn’t solve anything.
Without namespaces, you would just have a pile of classes to choose from.
Not all in the same solution file, though, so this is more of a theoretical problem than an actual problem.
Imagine if the System namespace was collapsed, it’d be impossible to get anything done!
The problem with this line of reasoning (and it isn’t limited to this example) is that 99% of developers aren’t working on anything even remotely as complex as the .NET framework itself. Eg the “we’re building the Space Shuttle” problem.
Quote - “C’mon. Let’s stop kidding ourselves. What does this accomplish? How many MhtBuilder classes are out there that I need to distinguish between?”
That particular statement smacks more of vanity than anything else. The reason for namespace is because there may be other MhtBuilder classes out there. You are not the only developer in the world.
One of the problems I often have with programming is coming up with good names. More specifically, if you thought you came up with a great name for a class and someone came up with the same name, and there are no namespaces to resolve current and possible future collisions.
How about coming up with better names for classes? MhtBuilder is not terribly descriptive, it tells me nothing about what it does. Of course, there are structures for that kind of metadata. Well-named object models tells you how things should work.
Here’s an alternative possible solution: Visual Studio could allow you to ‘remap’ namespaces when you add a reference to a DLL. So if the DLL you’re using is ‘Util.TheUsefulClassIWant’, you could remap ‘Util’ - ‘MyCompany.MyProject.External’, placing the classes where you want them.
That way you don’t need to convince the original author to rename it, and yet your code doesn’t need to contain references to monkeys or whatever.
The reason for namespace is because there may be other MhtBuilder classes out there. You are not the only developer in the world.
Agreed, so they can add whatever namespace they need if they have a conflict. And the rest of the developers don’t have to suffer through the excessive naming syndrome because 98% of them will never need it. YAGNI.
Of course for binaries this isn’t as easy (see fusion loader for possibilities) so it’s more viable there.
Visual Studio could allow you to ‘remap’ namespaces when you add a reference to a DLL
I’m pretty sure the .NET Fusion loader lets you remap assemblies at load time almost any way you want, via .config file overrides. So even if you did have that one-in-a-million naming conflict case, you could fix it.
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
I’m not against namespaces, I am against blindly adding a namespace to every bit of code you produce. It’s unnecessary.
The problem I see is that MhtBuilder isn’t exactly a great classname. You may argue that following the .NET Class Library Design Guidelines naming convention is YAGNI, but I think that depends on your point of view. Normally, you are going to name your classes something meaningful using complete words like. RelaxNGValidatingReader and there is a very good chance that you can have name collisions with such names. Plus, You are assuming that it’s your non-namespaced class versus mine, which I am free to put in a namespace. But what if it’s your non-namespaced class and some other 3rd party’s non-namespaced class both consumed in my application? Now I have to wrap both implementations in my own separate class libraries just to avoid collisions. If you want to go without namespaces, I think that’s ok. I agree for many quick utils that will never be distributed this may be the best approach. However, if you plan to distribute your code for someone else to use, then it isn’t too onerous to ask the developer to “play nice” within the Framework they’re living in and follow the conventions. In the Java world there’s the com.domain.* convention and it works pretty well for them. Personally, I prefer the .NET convention of CompanyName.Technology.* etc. Of course, for open-source, the question remains what company? I say make it the Domain Name of the server it’s distributed from if it’s a one-developer project CodingHorror.Xml.RelaxNGValidatingReader for instance. If it’s sourceforge or Apache sponsored, then sensible alternatives readily present themselves. But that’s just me. I could be wrong. 
I think namespaces are more useful as organizational tools than classname collision detectors. Without namespaces, you would just have a pile of classes to choose from. Imagine if the System namespace was collapsed, it’d be impossible to get anything done!
You can alias namespaces with using/imports.
Imports Microsoft.DirectX.Direct3d
Imports D3D = Microsoft.DirectX.Direct3d
allows
Private device as D3D.Device
You can use this to mask the stupid namespace name you don’t like.
Good call Jeff. Namespaces almost always slow down, confuse and devolve useful code more than it enhances it… and again you’re right, it’s purely egotistical to think most of this code we write is acutally even going to be around that long.
Thanks for daring thoughts like this. Keep it up.
I’m going to have to join with the “we love namespeaces” crowd.
I absolute love the fact that I don’t have to worry at all about name colliding. This is especially true for code library projects which are meant to be deployed in your application.
Namespaces also are a great help in naming and categorizing your classes.
How do you propose I rename all my classes which are in the Site.Framework.Web.Controls.* namespace? Am I expected to prepend SiteFrameworkWebControls to all my class names?
I come originally from Delphi and PHP world and I find namespaces to be a blessing! I even had to figure out a way to create namespace in JavaScript because developing JS applications which are meant to be plug-and-play, you have to be especially coutious about naming your variables.
I think namespaces have been simulated for ages…
include “…/framework/sockets/tcp.h”;
is the same as
using Framework.Sockets.Tcp;
only in the second solution I don’t have to worry that there might be another class called Tcp already in the system.
Just my $2.00
How do you propose I rename all my classes which are in the Site.Framework.Web.Controls.* namespace?
Well, I was thinking something like
Obscenely.Long.And.Rather.Grandiose.Universal.System.Web.Controls.*
But hey, that’s just me 
I see namespaces + intellisense, properly used, as a usability plus. One of my favorite features when I first started learning .NET was that I could type System. and browse and find almost anything. Now, it takes some effort to get your personal or company frameworks to that level of low-friction usability, but it’s worth it.
You say all you have to do is tell developers to start using ‘MhtBuilder’, but wouldn’t it be better if, for ALL code you released, they could get started by typing ‘CodingHorror.’? CodingHorror.Web.CompiledHtmlBuilder is my vote…
ALL code you released, they could get started by typing ‘CodingHorror’
I don’t want to instantiate a “Microsoft” or a “ComponentSoft” and especially not a “CodingHorror”-- how does that help me get work done? Who cares what the vendor’s name is; I’m interested in the functionality the component provides to my code.
I’d think many developers would find the vendor name useful when first trying out a framework. The thought process being something like: “I just referenced this framework I downloaded from CodingHorror, now how do I get it to compile Html? I know, if I type ‘CodingHorror.’, it’ll narrow my options a bit. Html is related to the web, so I’ll choose .Web. Ah, there it is…” Intellisense has just killed a few brain cells ;), but it got me what I needed without me needing to know the class to compile html is is named ‘MhtBuilder’
Now granted, once I’m familar with a framework, or if I’m the sort of developer who reads the docs first, then all that’s a burden. Then I add using or Imports and forget about it.
Seems elegant to me: your framework is extremely usable for both entry-level and advanced users.
The only problem with namespaces I have are in Java, where the convention is to match a company’s website. In C# or C++ at least you can use a short acronym or whatever for the namespace.
Removing namespaces is not a good idea, its like going back to the bad-old days of C coding; where the problem was to come up with method names that didnt exist. And I hate going through 100+ classes when I need a certain one because all of them exist in the same namespace, even worse if there is no namespace at all.
For instance, just writing “St” into VS, yields 30+ classes/properties/etc; without namespaces that would be much more, which would make intellisense much slower, which makes me a much slower coder…
For instance, just writing “St” into VS, yields 30+ classes/properties/etc; without namespaces that would be much more, which would make intellisense much slower, which makes me a much slower coder…
You’re assuming that everyone is writing the .NET framework. Is that a reasonable assumption?
HA HA HA, good for newbie like me, who ask whar namespace for . . .
Even though this is a fairly old thread, I’ll add my two cents…
I agree with previous posters that when you just referenced a so far unknown library, namespaces are a big help in conjunction with Intellisense.
For later use once I got used to the library, I simply type the class name that I’d like to use and let Resharper add the proper namespace. Additional cost: 1 second.