1

In the C++ community it is considered an extremely bad practice to type:

using namespace something;

in the scope of the file for any reason, even if the project size is only a few hundred lines at most.

However, other languages offer analogous constructs. We can, for example, do this in Python:

from some.thing import *

And this in Java:

import some.thing.*

etc, etc.

Yet I don't hear THAT MUCH frowning at these analogous constructs in other languages like in C++.

Is doing this in other languages just as ill-advised as in C++ and if not, then why?

  • This question might be a little too broad. I know C# has a using X feature so you don't need to use a fully qualified namespace for classes and members. It would be interesting to narrow this question down to c++ and C#. – Greg Burghardt Sep 29 '17 at 17:18
  • 1
    @GregBurghardt If this question is too broad, isn't the whole language-agnostic tag too broad? – gaazkam Sep 29 '17 at 17:27
  • No, the "language-agnostic" tag is not too broad. This question might be, because the reasons will differ between languages - not enough for me to cast a close-vote, though. – Greg Burghardt Sep 29 '17 at 18:03
  • I hear quite a lot of frowning in the case of Python. – Vincent Savard Sep 29 '17 at 18:06
  • I would ding people on a Java code review for doing this. If you can't be bothered to hit ctrl-shift-O or whatever it is your IDE, there's a problem. – JimmyJames Sep 29 '17 at 20:19
3

To my knowledge, importing a complete package into the current namespace is not frowned upon as much in Python and Java as it is in C++.

I think this has to do with how namespaces are integrated into the different languages.

In Java and Python, packages are tied to a directory structure and each package contains a fairly limited number of names (in the order of tens to a few hundred for very large packages). It is also not easy to add names later on without modifying the original packages.

In C++ on the other hand, a single namespace typically covers a complete library with hundreds or thousands of names and very little internal structure. Also, any source file can re-open a namespace declaration and add additional names. This means that if you do using namespace something;, you literally can't know what names you are dumping in your current namespace.

| improve this answer | |
  • Also, any source file can re-open a namespace declaration and add additional names. I'm not certain, but doesn't this apply to Python as well? – gaazkam Sep 29 '17 at 17:39
  • No, I don't believe you can add additional names to a package from a random file such that an import of the package in another file would also find the additional names as part of the imported package. – Bart van Ingen Schenau Sep 29 '17 at 17:56
2

(I'll use Java terminology in my answer).

Wildcard imports are a completely unnecessary maintenance risk. E.g. the Eclipse IDE's "Reorganize Imports" one-click function replaces them with explicit ones, for good reason.

The problem with such a wildcard import is that besides the symbols you really need you also get all the other symbols from the package. And if later someone adds a symbol to the package (new extended version of the library you use), you might get a name conflict.

With an import some.thing.*;, ANY symbol in your code might change its meaning, if someone else adds a class with this name to the some.thing package.

With explicit imports like import some.thing.Special;, only the symbol Special is affected (to unambiguously mean some.thing.Special), so there's no such risk.

Maybe in the Java community, wildcard imports aren't frowned upon so much because IDEs like Eclipse typically generate the imports on the fly, never using wildcards, so in production code you'll probably not find wildcard imports.

| improve this answer | |
2

There are two issues I can think of with the using namespace something; in C++.

  1. using and #include are transitive. If you write a public header file, which uses a namespace or includes another header file, then all consumers of your header file will transitively also use those namespaces, and include those header files. This makes you small "convenience" have a much further reaching impact than intended. This is not the case for Java or Python.

  2. When importing so many symbols en masse, you introduce a risk that a library/platform update can introduce a symbol collision. I ran into an issue with this once, from using import java.util.*, just for ArrayList, List, and some other common classes. When I updated to Java 8, my reference to Optional (my own class) became ambitious, because my wildcard import caused java.util.Optional to be imported.

In C++, Python, and Java, I would suggest using your IDE to generate using/import statements for each of your dependencies, without using the wildcard. E.g. using std::vector;

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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