Menu
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!
626
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.
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... ^_^
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++.
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 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):
Imports MyWholeProject
Class HelloWorld
Public Sub Main()
Dim o As MyModuleAAA_MyObject = New MyModuleAAA_MyObject
Dim t As MyModuleBBB_MyThing = New MyModuleBBB_MyThing
Dim g As MyModuleCCC_MyGizmo = New MyModuleCCC_MyGizmo
REM etc.
End Sub
End Class
Is quite more verbose than the namespace enabled:
Imports MyWholeProject.MyModuleAAA
Imports MyWholeProject.MyModuleBBB
Imports MyWholeProject.MyModuleCCC
Class HelloWorld
Public Sub Main()
Dim o As MyObject = New MyObject
Dim t As MyThing = New MyThing
Dim g As MyGizmo = New MyGizmo
REM etc.
End Sub
End Class
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
Those reasons are more relatived to project/career management...
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...)
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".
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...
117
The proper use of namespaces is to provide an orderly structure of logically grouped classes, interfaces, enums etc. It's like putting all your files in a single folder... or worse, putting them all in the root of C: drive...
Far be it for me to point out that your team is being extremely shortsighted, it's not really my place to start questioning other teams policies and procedures - but if I were in your position, I'd stick to my guns.
43
Hopefully your team understands object-oriented design principles. You group related information into classes that have operations that work on that information. Namespaces are (or should be) similar. You use namespaces to group related classes together and together they provide operations to work on the collective information of the namespace.
This helps with code intelligibility. Grouping your data layer classes into a single namespace identifies them as related, and related in a way to provide the functionality indicated by the namespace [As an aside, this is why you would need to provide meaningful names for your namespaces as well as your classes]. If you group all of your classes in the same namespace, then it all becomes a big ball of mud. You've lost the semantic clues to the organization of the code and have to dig through it to find out which classes work together to provide the required functionality.
The point is: it's not merely a matter of personal preference. In the same way that you can't expect to pour all of your sentences in to a single paragraph, but rather have to organize them into several paragraphs, in which the sentences are related; you need to take your classes and organize them into namespaces. Breaking your writing up into paragraphs of related sentences provides clarity and meaning, breaking your classes into namespaces improves the clarity of your code. As the number of classes grows, this only becomes more and more important.
30
While you are absolutely correct that namespaces are good, wholesome and completely necessary, it sounds like considerable effort has been put forth to establish the status quo on your team. The only way I think you have a chance of selling the idea is to:
Set hard numbers on the cost of not having namespaces (maintainability, debugging, etc.) and get executive management on board.
Volunteer to create the namespacing conventions and do ALL the work to convert the projects over.
Unfortunately, in my experience once something as pervasive as namespace convention has been established, it takes an act of Congress to get it changed.
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
