organizing you source code

Because of my involvement with the Design Guidelines effort I often get asked about “coding conventions” such as tab v. spaces, where to put the open brace, etc. My usual policy is not the chime in… these issues have a ton of religion around them and little value to external customers. But I, I was asked by one of my readers so thought I’d write a little about how the Framework organizes it’s source code and what works and what doesn’t. Essentially the idea is to have a root directory for each assembly MsCorLib, System.Dll, System.Web.Dll, etc. In those directories we have subdirectories for each namespace and each type gets its own cs file.

So String would be in:

\MSCorLib\System\String.cs

And FileStream would be in:

\MSCorLib\System\IO\FileStream.cs

This is an organizational structure that helps a ton in terms of finding and separating source. You can see this yourself if you look at the Rotor source.

As we got close to the end game for V1, we broke this pattern in the framework tree when we refactored types into several different assemblies, and merged some other assemblies into one (mostly for performance reasons). There are a few assemblies such as System.dll that now pull in code from ~6 different directories scattered throughout the tree. It takes a lot more effort (or memorization) to find types the source for types that live System.dll. Our dev team is not crazy about that as it increases the time to find the source for types…mostly they give up and type "dir /s". At least we generally keep to one class per file, so "dir /s" is usually successful.

Comments

• Anonymous
  June 12, 2004
  You can use the VS File Finder plugin, maybe this helps a little bit (at least for me, it does :-)): http://www.codeproject.com/dotnet/VS_File_Finder.asp
• Anonymous
  June 13, 2004
  I assume that you're not actually doing them as MSCorLib, but rather something in the recommended MSBuild style, projectsnamemain, projectsname1001 etc, otherwise how are you going to deal with branching and pulling old versions out to fix problems without rolling out all your changes?
• Anonymous
  June 13, 2004
  That is fair, it is actually "ndpclrsrcbcl", but I didn't want confuse the issue...
• Anonymous
  June 13, 2004
  I've seen the projectv1.0, projectv2.0, etc at work... It's not pretty when systems get big.
  
  I would imagine a src tree such as the framework would maintain seperate trees for the major versions...
  
  v1.0
  |--mscorlib
  |--System
  |-- ...
  
  v1.1
  |--mscorlib
  |--System
  |-- ...
• Anonymous
  June 13, 2004
  ahh, my spaces were eaten....
  
  that was supposed to be a tree, System under mscorlib.... :-)
• Anonymous
  June 15, 2004
  How to organize your Visual Studio project to best leverage namespaces.
• Anonymous
  July 15, 2004
  It is logical to have each namespace a directory and each class a file. It is also logical to keep version trees separate. My question is, should we include major version information in the namespace root.
  
  namespace XYZ.MyProject.V1.Reports {}
  namespace XYZ.MyProject.V2.Reports {}
  
  and then just change the imports/using statements to include new versions.