MSFT took all the good namespaces

  • Thread starter Thread starter Raymond Lewallen
  • Start date Start date
R

Raymond Lewallen

It could help if you understood the project I work on a bit, but I can't
tell you anything about it, so do the best you can under that pretense.

Lets say you have a global assembly supporting multiple applications. In
that assembly, you have mass amounts of classes classified as such:
functions that get data, instantiated functions that process large amounts
of data, shared functions that process small bits of information, like some
string conversions at such, and you also have a number of other specialized
classes. To me it makes sense that you would have:

MyAssembly.Global.Data - data retrieval classes
MyAssembly.Global.Process - data processing classes
MyAssembly.Global.Methods - classes with shared functions/subs
MyAssembly.Business.Support - friend classes to support Global namespaces
MyAssembly.UI.Base - base classes to support UI

etc, etc. Now, FxCop pukes at this naming convention, understandably
(doesn't like Global, Data, Process and some others not mentioned here).
Since MSFT has used up the good and obvious namespaces and you don't really
want to duplicate those in other assemblies to avoid confusion, what is one
to do to come up with a solid and logical naming convention for namespaces?

Do you just go ahead and use obvious namespaces, or is there some other
rules out there that everyone is implementing in these circumstances?

Just looking for thoughts on how to group and names these namespaces.

Raymond Lewallen
Federal Aviation Administration
 
In news: (e-mail address removed),
Raymond Lewallen said:
MyAssembly.Global.Data - data retrieval classes
MyAssembly.Global.Process - data processing classes
MyAssembly.Global.Methods - classes with shared functions/subs
MyAssembly.Business.Support - friend classes to support Global
namespaces MyAssembly.UI.Base - base classes to support UI

etc, etc. Now, FxCop pukes at this naming convention, understandably
(doesn't like Global, Data, Process and some others not mentioned
here). Since MSFT has used up the good and obvious namespaces and you
don't really want to duplicate those in other assemblies to avoid
confusion, what is one to do to come up with a solid and logical
naming convention for namespaces?

Do you just go ahead and use obvious namespaces, or is there some
other rules out there that everyone is implementing in these
circumstances?

Just looking for thoughts on how to group and names these namespaces.
Click to expand...

Hi Raymond,

My thought is to use a prefix of some sort. Since you're with the FAA I'd
use something like

MyAssembly.faaGlobal.faaData - data retrieval classes

The point that these are global data classes still comes across to
developers. I'm sure others will have different ideas.
 
Raymond Lewallen said:
It could help if you understood the project I work on a bit, but I can't
tell you anything about it, so do the best you can under that pretense.

Lets say you have a global assembly supporting multiple applications. In
that assembly, you have mass amounts of classes classified as such:
functions that get data, instantiated functions that process large amounts
of data, shared functions that process small bits of information, like
some
string conversions at such, and you also have a number of other
specialized
classes. To me it makes sense that you would have:

MyAssembly.Global.Data - data retrieval classes
MyAssembly.Global.Process - data processing classes
MyAssembly.Global.Methods - classes with shared functions/subs
MyAssembly.Business.Support - friend classes to support Global namespaces
MyAssembly.UI.Base - base classes to support UI

etc, etc. Now, FxCop pukes at this naming convention, understandably
(doesn't like Global, Data, Process and some others not mentioned here).
Since MSFT has used up the good and obvious namespaces and you don't
really
want to duplicate those in other assemblies to avoid confusion, what is
one
to do to come up with a solid and logical naming convention for
namespaces?

Do you just go ahead and use obvious namespaces, or is there some other
rules out there that everyone is implementing in these circumstances?

Just looking for thoughts on how to group and names these namespaces.
Click to expand...

I would simply tell FxCop to stuff it and use what you want(well, I may look
to avoid global or a few other words that might be considered *common* terms
in other langauges). Some small changes could be made: Process =>
Data.Processing, Data=>Data.Access if you really wanted to, but for the most
part it really isn't an issue.
Just don't use the namespace System *anywhere* and you should be ok. System,
Microsoft, or any other common toplevel namespace can crush you in C#, but
little else should. I would make your decision based entirely on the
languages standardized in your company and remove the rules from fxcop that
you dislike. If you are using C# and intend to move to C# 2.0 in the near
future, you should also probably examine extern aliases and the new
namespace operator and make concessions for them.
 
Back
Top