Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been programming in various languages for about 10 years now. And I still haven't figured out when it is a good idea to import something into the global namespace (using x::y in C++, from x import y in Python etc.), so I hardly ever do it.

It almost always seems like a bad idea to me, if only because it limits the set of variable names I can use. For example: Where I to use using namespace std; or using std::string;in C++, I couldn't use stringas a variable name anymore, which I occasionally do (e.g. for string utility functions).

But I'm wondering: Are there some situations where importing a name into the global namespace really makes sense? Any rules of thumb?

share|improve this question
add comment

4 Answers

In C++, it's generally frowned upon- especially using namespace std. That std namespace has so many names, many of which are very generic algorithms, you can get some extremely nasty surprises when using namespace std. Something like using std::cout; isn't so bad. But never, ever, using anything into the global namespace in a header file. That's a firing-squad offence.

share|improve this answer
    
But what about my question? When to use using x::y or import x from y? –  futlib Feb 11 '13 at 5:55
add comment

You should do it when it simplifies your code. You shouldn't do it when it would cause naming conflicts, or when it could be later brought into scopes where it would cause naming conflicts, such as a header file.

Some people think it should be rare. I think (outside of header files) not using it should be rare, because the namespace prefix doesn't generally add any useful information, like using someone's full name every single time you address them.

Let me put it this way. When you see string as a class name, do you automatically think std::string or mycustom::string? It's like the old adage. When you hear the sound of hooves, you think horses, not zebras. In other words, using namespace std is almost always no big deal. using namespace mycustom is likewise usually not a big deal, unless it contains a conflict with std, in which case your custom namespace is the one you want to always require the prefix for.

share|improve this answer
    
What happens if mycustom contains a string class. At the top you using namespace mycustom;. Through the rest of the code you now use string. Everybody else that reads the code is thinking std::string only you (and a few very observant people) are thinking mycustom::string. Here you have put the zebras in the horse paddock. Also see stackoverflow.com/q/1452721/14065 –  Loki Astari Mar 2 '13 at 16:27
1  
Did you not read my last sentence? I specifically said if mycustom conflicts with std you should always require the mycustom:: prefix. –  Karl Bielefeldt Mar 2 '13 at 18:03
    
I did. The trouble is that most namespaces are non trivially large. Knowing everything in them is even harder (and future versions of the namespace may expand). Thus including a whole namespace is a recipe for disaster (using specific items (within a small specific scope is easier to control)). If your code contains doStuff(int). And a newer version of mycustom adds doStuff(double) then the whole meaning of any call to doStuff(5.5); changes (potentially without you noticing). –  Loki Astari Mar 2 '13 at 18:59
add comment

Working in Python, I use from x import y (as z) constantly, to have clear, concise names to reference imports.

From imports are invaluable in a codebase with a deep namespace hierarchy. This is especially so when the style standard for the codebase is PEP 8, which limits line length to under 80 characters.

For example, consider:

import foo

foo.bar.baz.baf.perform_task(foo.bar.baz.quux.SOME_CONSTANT, foo.bar.alice.bob.preferred_hash_function, '42', foo.bar.magic_numbers.MY_SALT)

Which could instead be written:

from foo.bar import baf
from foo.bar.alice import bob
from foo.bar.baz.quux import SOME_CONSTANT
from foo.bar.magic_numbers import MY_SALT

baf.perform_task(SOME_CONSTANT, bob.preferred_hash_function, '42', MY_SALT)

Since Python identifiers are case-sensitive and unlimited in length, we won't run out of names regardless of how many we import.

If we want to use the same name in our module as one of the modules we wish to import, we can use an alias for the import:

from foo.bar.alice import bob as carol

def bob(x, y):
    print "running bob function"
    return carol(x, y, 42)
share|improve this answer
add comment

It's up to programmer when to use it. IMHO it's better not use them at all, especially in header files. But there are several cases when I use it

  • When I want to introduce something to another namespace e.g.

    namespace cg
    {
      namespace details
      {
        //lots of stuff
        void some_cool_foo()
        {
          //uses a lot stuff from details, here because I don't want prefix everything with details::
        }
      }
      using details::some_cool_foo;
    }
    
  • To enable ADL for some algorithms from another namespace

    namespace n1
    {
    //some general foo
    }
    namespace n2
    {
      using n1::foo;
    //some struct
    }
    namespace n3
    {
      using n1::foo;
    //some struct
    }
    

If I don't want write long names of namespaces at .cpp I can always make alias

namespace bl = boost::lambda;
namespace fs = boost::filesystem;
share|improve this answer
    
sorry, could not make it highlight my source =/ –  kassak Mar 2 '13 at 11:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.