• 10
• 12
• 12
• 14
• 15

# [Debate] Using namespace should be avoided ?

This topic is 803 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

What do you think about "using namespace" ?

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

Edited by Alundra

##### Share on other sites

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.

Edited by Buckshag

##### Share on other sites

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.

##### Share on other sites

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:

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.

Edited by imoogiBG

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

Edited by Aressera