There is actually a (subtle) difference between the two. Imagine you have the following code in File1.cs:
static void Bar()
double d = Math.PI;
Now imagine that someone adds another file (File2.cs) to the project that looks like this:
The compiler searches
Outer before looking at those
using directives outside the namespace, so it finds
Outer.Math instead of
System.Math. Unfortunately (or perhaps fortunately?),
Outer.Math has no
PI member, so File1 is now broken.
This changes if you put the
using inside your namespace declaration, as follows:
static void Bar()
double d = Math.PI;
Now the compiler searches
System before searching
System.Math, and all is well.
Some would argue that
Math might be a bad name for a user-defined class, since there's already one in
System; the point here is just that there is a difference, and it affects the maintainability of your code.
It's also interesting to note what happens if
Foo is in namespace
Outer, rather than
Outer.Inner. In that case, adding
Outer.Math in File2 breaks File1 regardless of where the
using goes. This implies that the compiler searches the innermost enclosing namespace before it looks at any
Prefixing your classes with a unique prefix is fundamentally the only option but there are several ways to make this less onerous and ugly. There is a long discussion of options here. My favorite is the
@compatibility_alias Objective-C compiler directive (described here). You can use
@compatibility_alias to "rename" a class, allowing you to name your class using FQDN or some such prefix:
@interface COM_WHATEVER_ClassName : NSObject
@compatibility_alias ClassName COM_WHATEVER_ClassName
// now ClassName is an alias for COM_WHATEVER_ClassName
@implementation ClassName //OK
ClassName *myClass; //OK
As part of a complete strategy, you could prefix all your classes with a unique prefix such as the FQDN and then create a header with all the
@compatibility_alias (I would imagine you could auto-generate said header).
The downside of prefixing like this is that you have to enter the true class name (e.g.
COM_WHATEVER_ClassName above) in anything that needs the class name from a string besides the compiler. Notably,
@compatibility_alias is a compiler directive, not a runtime function so
NSClassFromString(ClassName) will fail (return
nil)--you'll have to use
NSClassFromString(COM_WHATERVER_ClassName). You can use
ibtool via build phase to modify class names in an Interface Builder nib/xib so that you don't have to write the full COM_WHATEVER_... in Interface Builder.
Final caveat: because this is a compiler directive (and an obscure one at that), it may not be portable across compilers. In particular, I don't know if it works with the Clang frontend from the LLVM project, though it should work with LLVM-GCC (LLVM using the GCC frontend).
From the Namespace Naming Guidelines:
Generally it's a really bad practice to start including things into the default namespace of a framework or library. This can cause confusion in terms of whether a new namespace is part of the existing library that is part of a framework that is distributed to everyone, or is part of a custom framework that was added by someone else.
Also, the naming convention tries to avoid namespace collisions by having unique identifiers such as
CompanyName. It also reduces any confusion and issues in terms of the source of the new library.
This is not only a Microsoft thing, but in the Java as well. Namespaces in Java, called "packages" has the following convention:
So, if I had a super awesome piece of software, it may be in the
And using package names that contain the default
com.sun.packages are a big no-no.