Code maintenance is a serious issue these days. Not only is it a matter of managing where your files reside but also how your ever-growing library of classes is organized. A messy object model leads to chaos and confusion, whereas a clean and well-developed hierarchy promotes better code and enhances productivity. In this article on general component development, I'll show you how my company, Interscape Technologies, manages namespaces and source code.
Not every company has the luxury of having its product and brand name define the industry like, for example, Kleenex. Interscape is currently pushing a brand called Codeside Assistance. In my namespace, I take advantage of the opportunity to familiarize my end users with my brand before even fully developing the marketing for it.
Interscape's namespacing is organized into the following pattern:
To show how this works, I'll use my GenX.NET example from my previous article, "Developing components: Assembly identification." GenX.NET falls under the Codeside Assistance brand, so its namespace is Interscape.CodesideAssistance.GenX. The rest of Interscape's namespace hierarchy is as follows:
As you can see, this method is very simple and allows for consistency not only in your code but also across product lines and brands. As the developer uses your component, he or she will subconsciously build brand familiarity.
Source code management
For source code storage and control, my company and I both use the GotDotNet Workspaces. For those of you unaware of this application, the Workspaces are an open source community written and provided free by Microsoft. Yes, you heard right. I did say open source, free, and Microsoft in the same sentence.
If this surprises you, you obviously haven't seen the ASP.NET Starter Kits or Web Matrix. But before you start comparing Workspaces to something out of the movie Antitrust, Microsoft has a very clearly defined user agreement that states your source code will only be stored and not viewed.
Interscape's Workspace organization goes hand in hand with the namespace organization I discuss in this article and the versioning policy I discussed previously. Taking that into consideration, Interscape's Workspace folder hierarchy uses the following pattern:
Again, if you're using Interscape's product line as an example, and you opened our Workspace right now (which you can't because it's private, but that's beside the point), you would find:
Every time I hit a development milestone, I increment the build number and create a new folder in my Workspace so I can keep track of the code progression through each milestone. It comes in handy when bugs creep into previously working code between milestones.
So there you have it: a simple, consistent, and effective method for managing your constantly growing library of code. Be sure to drop me a line in the article discussion and tell me what you think. Does it work for you? Do you have a better way? Let the community know so we can all write better code.