[Debate] Using namespace should be avoided ?

Started by
15 comments, last by Bearhugger 8 years, 2 months ago

Hi,

What do you think about "using namespace" ?

Personally I think it's not explicit then when you use it and can give confusions.

Advertisement
Using any namespace at header level is a good way to make a not-friend out of me. I strongly discourage using any namespace at file scope. Using namespaces at function scope is occasionally useful or required (see Swappable).

In my own code it practically never happens (with the exception of things like using std::swap).

I think it depends on the situation.

You should never use it inside a .h file in my opinion.

Code readability goes down a bit by not using it, but it is more clear what classes belong to what namespaces, so maybe that compensates for it again.

If your own engine uses only one core lib for example it is perfectly fine to do "using namespace CoreLib" inside your .cpp files in my eyes.

If however you later plan to add support for another library that happens to have the same class name, you have to explicitly name that one.

I personally prefer not to use "using namespace", as then you are always safe (unless there is a lib with the same namespace name lol).

I think generally it should be avoided, but in some cases it is fine I think.

using namespace has little to no way of being disabled once it is declared. Which is why at header level can be a PITA.

At .cpp file level it sounds more sane. But if you try "Unity builds" to speed up compilation, using namespace at .cpp file level comes back to bite you. Which makes "using namespace" more friendly at an enclosed scope, e.g.:

void myFunc( int a )
{
     using namespace std; //Only available at myFunc level.
}

Typing std is not a big deal, so I try to avoid it as much as possible. Furthermore it "using" pollutes autocomplete.

There are legitimate cases where it's appropriate, but use with discretion, with care.

Assuming that nobody uses "usign namespace" in headers,I don't like(and use) it because :

- Eventual collision. This usually doesn't happen.

- Searchinng won't work that well with something form the namespace.
- the header declaration does not match the cpp definition of a function that uses type form the namespace example:
Header:


class foo{
void boo(std::string& s);
}

Cpp:


using namespace std;
void foo::boo(string& s) { .. }

This this basically breaks the "code searching". Additionally it make it a little bit harder to change/move the code.

This issue will be resolved when we have modules in C++. Until then we shouldn't pretend that this is Java/C#(namespaces work like a charm there).

- other things that I cannot remember.

Furthermore it "using" pollutes autocomplete.


using namespace has little to no way of being disabled once it is declared. Which is why at header level can be a PITA.

That's my problem with it as well.

Do not ever use it in a header file. That would get you called out quick at a code review around here.

Also, using a full namespace is bad because it pulls in everything. If you want to pull in a few specific functions or values that is fine, but the whole namespace is generally overkill.

In your own CPP file you might be able to get away with it, but generally not recommended around here. Specifying which library or subsystem you are pulling your types from is generally better for those who come after than the few keystrokes saved by a using statement. The vast majority of the code base specify their namespaces. Sometimes that isn't the case, but generally we discourage it.


If you want to pull in a few specific functions or values that is fine, but the whole namespace is generally overkill.

This.

I've found in my own code I tend to do this, but even then I try to keep it at function scope.

"I can't believe I'm defending logic to a turing machine." - Kent Woolworth [Other Space]

1st of all it thrashes global namespace and 2ndly IDEs provide huge list of irrelevant suggestions. I'm trying to even get rid of windows.h include because of that.

It's not always bad...

I use it in my codebase, even in headers, but ONLY within the scope of another namespace, never in the global namespace, and only when it is clear that the imported namespace is a strong dependency of the enclosing namespace. In my case, all of the code is part of the same suite of libraries which are meant to interact and depend on the same base code, so I allow it to avoid literally thousands of verbose explicit namespace qualifiers in header files. The tradeoff is worth it in this case, I think.

e.g.

EngineConfig.h:


#include "Graphics.h"
#include "Physics.h"
#include "Sound.h"
namespace engine {
using namespace graphics;
using namespace physics;
using namespace sound;
};

In most cases I prefer importing just the needed classes, but once the import list grows beyond 5-10 classes from the same namespace, I tend to import the entire namespace instead if it makes sense.

When I really need a namespace because I will use some of its features I'll just scope it under a class that uses it (Mainly std).

This topic is closed to new replies.

Advertisement