How do you use namespaces?

Namespace are pretty cool: with them, you can organize your libraries and you can avoid name conflicts.

Well, this is the intention, I think. I think that a lot of people do not use it like it should be used... Every day, I see 95 char long namespaces scattering the code and hiding the really important information.

Here is an example:

BigCorp.FrontOffice.MyApp.MySubDomain.Controllers.MyControllerXYZ xyzController = new 
    BigCorp.FrontOffice.MyApp.MySubDomain.Controllers.MyControllerXYZ( 
        BigCorp.FrontOffice.MyApp.MySubDomain.Const.MyValue1,
        BigCorp.FrontOffice.MyApp.MySubDomain.Const.MyValue2 );

Did you got the intention here? No, of course. It was:

MyControllerXYZ xyzController = new MyControllerXYZ( MyValue1, MyValue2 );

Pretty simple without namespaces but unintelligible with...

Well, how do you use namespaces? What are your best practices about them? Should we use namespaces or inner classes? How many namespaces your main project is using? (Currently, mine is using 210 interfaces(!) and much much more namespaces -- unmaintenable!)

In advance, thanks for your answers,
Sylvain.

From stackoverflow

• A similar question was asked here. Perhaps that could help. My $0.02 Cents

  Sylvain : Great link - thanks !

• This depends on the language and the breadth of the organization and code. You're right that having a long list of namespaces scattered throughout the code makes it harder to read. But they do have a good purpose: code organization. Does your language give you the ability to alias these domains, or just to include the names once at the beginning of the file, via a "using" or "imports" statement? If that's the case, then in the body of code, you only need namespaces where they conflict.

• Assuming that you are talking about namespaces in C#, besides the obvious usage of

  using Namespace;
  

  you can also have aliases:

  using ShortCut = Really.Complicated.Namespace.Its.Just.Terrible;
  

• thats a lot of questions in one question post!

  1) Why use Namespaces? as you stated in the question, they are AN orginizational method for code. there really is no "one way" to orginize code so commonly named objects arn't causing you issues. Creating one class library might use an entirely different mechinism than another library.

  2) How should I use namespaces? I prefer how Microsoft has grouped their namespaces (see 3.5 name space map!). Group by functionality, inheritance, whatever! namespaces are just another orginizational tool to be used. That being said, I err on the side of less is more. as you said, namespaces can obscure code, as well as hide functional code from other developers (which namespace had that gridrow class i needed? Grid or Row?). I try to only use namespaces when the need arizes. Call me sloppy, but it has worked for me so far!

  Summary: avoid complexity. don't over categorize your code.

• thinking about this theoretically (i very rarely use namespaces myself), i'm not sure how much namespaces help. in order to keep the code readable, you're going to try to choose clear names for your functions and variables anyway. as well as this, most languages support scope setting to restrict visibility of functions or variables in some manner. and a function itself provides in most languages a natural namespace for variables within.

  it's a general question about how to name variables. is a declaration

  int x;

  best regarded as an easy to validate form of

  intx; ?

  when the programmer already knows it's an int, writing something like

  int myint;

  is tautological. worse than this, declaring a variable as

  int x;

  stops you writing

  double x;

  in the next line, while keeping them as one word does not. as well as this, you have to remember when you code that x is an int or that y is a double. this is why people write

  ByteArrayOutputStream myByteArrayOutputStream = new ByteArrayOutputStream(size);,

  so that they know exactly what the variable is. this ends up being very tautological. if you're going to call it myByteArrayOutputStream anyway, why does the grammar of the language force you to explicitly enter the class?

• We have folk here who tend to do that. They also tend to proceed to use "using" clauses to get rid of the cruft. The silly part is that just leaves them right back where they started.

  Generally what I like to see is one, and in rare cases two, levels of namespaces. What you should do is the following: every time you are tempted to stick

  foo_

  on the front (or back) of a bunch of identifiers, instead put them all together into namespace "foo" and call them with

  foo::

  That way the wart you were going to put on there anyway now has some syntactic signifigance. Even better, in the internal code for the "foo_" stuff, you no longer have to use the leading "foo". It is understood, since you are already working on an item in the "foo" namespace. This makes the internal code much easier to read and the client code marginally easier to understand.