My team is working on a conversion project to convert one product (but with many facets) from VB6 to .Net (we have over ~300k LOC). Before I got on board, the decision was made that regardless of the location of the assembly, or folder structure, all classes / structs will be in one namespace:
.
They even go as far as changing auto-generated application settings designer code, resource designer code, and such to force uniformity. How do I convince them that namespace use is good? What is the proper use of namespace and what are the pros and cons? I guess I am having a tough time understanding why my colleagues would go through so much hassle to save a few using lines. Any external, reputable references to support your argument would be much appreciated. Please help!
Good answers, already
I read a lot of good answers (the drive folder’s image is a good one, for example, as is the object/concept separation/organization).
Still, some other, less ‘technical’ arguments could help, not to explain why namespaces are better than the alternative, but to unearth the bad reasons namespaces are not used.
Argument by Authority
Every C#, VB.NET, Java, C++, whatever developer worth its salt on this planet acknowledge namespaces/packages are a good thing. Hey, they are even considering it in Mozilla’s JavaScript.
I guess that your question on Stack Overflow has the ‘Authority Argument’ touch… ^_^
Old Habits die hard
I believe you are falling in a case of ‘Old habits’.
While I have no direct experience about VB.NET against VB6 old habits, I do for C++ against stripped-down C-like, C++.
Half the work…
When dealing with legacy habits, half the work is discovering they already use namespaces, without acknowledging it.
For example (this is most true for C++ devs colliding with ‘old fashion’, C-like code, but it is viable everywhere, I guess), do they use prefixes for their symbols.
Do they have:
classes/symbols, and explain that the ‘User’ of Account is not the same than the ‘User’ of login, and thus, the prefix to differentiate them?
The ‘pattern’ go right through the ceiling when they prefix their symbols by module (which is certainly the case for your code, if it is large enough):
Do you have a MyUtil DLL, as well as MyKernel DLL and a MyGui DLL ? Thus, do you have:
classes/symbols?
If yes, then they should acknowledge they are already using namespaces.
If not, then either your codebase is too small (but your ‘9 projects’ tell me it’s not), or they are regularly problems of name collision… Which can be resolved either by the prefixing explained above, or even better, by namespaces.
The other half…
The other half of the work is making them explain why their ‘namespaces’ are better than the one built-in in the language (this is the moment you should keep from banging your head against the walls in frustration because of lethal exposure braindead reasoning).
Again, you can use the Argument by Authority thing (What? You do believe know better than the Top Gun engineers from Microsoft?), but in this case, you should give examples of why the .NET (or whatever) namespaces are better than the one they use (or don’t use).
For VB.NET/.NET, there already more than enough good arguments, and I won’t go on the ones behind C++ namespaces because it would be out of topic.
But at the very least, using built-in namespaces makes the prefix mentioned above optional. Quoting an example from internet (I’m not very knowledgeable of VB.NET):
Is quite more verbose than the namespace enabled:
And verbosity lead to more obscure code, and thus bugs. Of course, you could replace MyModuleAAA by something less long, like MMAAA… But then, it leads to more obscure code, etc. etc..
More uses of namespaces on .NET can be found by Googling, like: http://www.vbdotnetheaven.com/UploadFile/ggaganesh/NamespacesInVbDotNet04202005005133AM/NamespacesInVbDotNet.aspx
Project/Career related reasons
Those reasons are more relatived to project/career management…
Maintenance is not optional
If your application is an old dying cow, where changing a label or the content of a combo is worth 2 days of work (it does happen) then there is no point, perhaps, to an extra-work of refactoring. In the other hand, if the refactoring is automated, then you should do it anyway.
But if your application is supposed to be used in the future, then sabotaging it to keep it in the past is a bad idea. You’ll pay for it, someday. Each hour supposed to be won by avoiding maintenance will be paid twice or tenfold the day it will become unavoidable (you know, the day when you won’t have time to do it properly because it is urgent…)
Keeping oneself up-to-date is not optional
This argument is for engineers, who have a career, and must keep their job: Like applications, software engineers can become obsolete.
And it means that the obsolete developer, when applying to another job, will lose, too. Because, hey, who wants to pay for someone who just don’t get something as simple as namespaces?
Experience is a good thing when it is coupled with knowledge of current state-of-the-art. If not, then it’s only dinosaur-old cynical and useless rambling about ‘how it was better(read: simpler), in my time, when we did not need all those gizmos like objects‘.
Keeping oneself up-to-date is not optional (manager side)
By refusing to adapt to new features of the language (usually because ‘we know better, you know?‘), engineers are just putting on concrete shoes while the competition is probably putting running shoes. This mean the application produced by an obsolete team will eventually lose. Period.
In a similar fashion, the team will hire new engineers, who probably know about the features, and who will become surprised, and then frustrated about the fact they are just programing like their grand-mothers did decades ago. The obsolete team won’t keep new engineers very long (at least, the ones worth their pay).
Note that working on an obsolete product make it easier for top-level managers to decide it would get easier to rewrite it from scratch… And possibly somewhere else, with less-paid engineers and managers…