[zrobotics]

Definitely very true. I write more C++ than anything else, and the sheer number of online examples that start with

  using namespace std;

is just staggering. Sure, it works in a toy example posted to stackoverflow, but it will cause problems in larger projects. I think globally there needs to be better emphasis on using best-practices in tutorials and examples; I remember this particular pet-peeve of mine also being present in college textbooks. Especially for content aimed at newbies, it should be frowned upon to show the wrong way to do things, since then it gets harder to show how to do it the right way. I've had people who were surprised to find out that they could type:

  using std::chrono::duration;
  using std::cout;

instead of pulling in the entire std namespace; simply because they'd only ever seen examples that did it the lazy way.

edit: lack of semicolons strikes again!

[nemetroid]

While I agree with the general point of using best practices in code samples, the Cpp Core Guidelines actually encourage[0] using

  using namespace std;

for std specifically, giving the reasoning that:

> sometimes a namespace is so fundamental and prevalent in a code base, that consistent qualification would be verbose and distracting.

I also work mainly in C++, and personally I prefer using it, together with -Wshadow to catch possible issues.

0: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

[jhasse]

Problems arise when you upgrade your compiler and a new symbol was added to std::

[ajross]

That's... true in the specific example, becuase C++'s standard library is a huge, promiscuous mess of obvious-looking symbol names that are just asking for a collision with a user name.

But in general the notion that we want to isolate "everything" into a namespace is a net loss. Clear and simple abstractions have real value, and short undeclared names are an important part of being clear and simple.

The modern convention of separately importing every symbol you use gets really out of hand, when most of the time it really is appropriate that you just declare "my code is using this API" and expect things to work without having to link your program by hand with a giant shipping manifest of symbols at the top of your source files.

[rcfox]

I strongly disagree. In Python, you can find exactly where every identifier comes from (unless you use `from foo import *`, but that's frowned upon) and it makes it extremely easy to navigate code and documentation.

I've had to look at some C# web service code recently, and the amount of magic it relied on made it impossible for me to find what I was looking for, even using grep.

[ajross]

And I strongly repeat that well-understood and commonly-used APIs benefit (strongly, heh) from concision and idiom.

Seriously, when was the last time a C programmer needed to figure out where identifiers like "strlen" or "fread" come from? The problem you posit need not exist for big chunks of commonly used APIs, and the inability of modern programmers (trained, it seems, on C# web service code) to see that is frustrating.

[Too]

> Seriously, when was the last time a C programmer needed to figure out where identifiers like "strlen" or "fread" come from?

http://www.suodenjoki.dk/us/archive/2010/min-max.htm

[zrobotics]

But isn't something like

  from tk import *

essentially equivalent to my C++ example? They're bad practices in both languages. Thankfully python examples seem to be better in this regard, since I don't recall seeing wildcard imports in any of the tutorials or references I've used.

[rcfox]

Yes, and it does make code more difficult to read. I've looked at a fair amount of Python code, and it is very rare to see import * in the wild.

On the other hand, import * is nice to have in a repl.