老实说，对我来说，这就像讨论缩进空间的数量。

在标头中使用指令会导致损坏。但是在C++文件中呢？如果同时使用两个名称空间，可能会发生这种情况。但如果你使用一个，它更多的是风格而不是真正的效率。

你知道为什么关于缩进的线索如此流行吗？任何人都可以说些什么，听起来非常聪明和有经验。

考虑两个名为Foo和Bar的库：

using namespace foo;
using namespace bar;

一切都很好，你可以从Foo调用Blah（），从Bar调用Qux（）。但有一天你升级到了Foo 2.0的新版本，它现在提供了一个名为Qux（）的函数。现在出现了一个冲突：Foo 2.0和Bar都将Qux（）导入到全局命名空间中。这将需要一些努力来解决，特别是如果函数参数恰好匹配。

如果您使用了foo:：Blah（）和bar:：Qux（），那么引入foo:：Qux（）将是一个非事件。

如果您导入了右侧的头文件，您的全局范围中会突然出现十六进制、左侧、加号或count等名称。如果您不知道std:：包含这些名称，这可能会令人惊讶。如果您也尝试在本地使用这些名称，可能会导致一些混淆。

如果所有的标准内容都在自己的命名空间中，那么就不必担心与代码或其他库的名称冲突。

不要全局使用它

只有在全球范围内使用时，它才被认为是“坏的”。因为：

你把正在编程的命名空间弄得乱七八糟。当您使用许多名称空间xyz；时，读者将很难看到特定标识符的来源；。无论对你的源代码的其他读者来说是什么，对最经常阅读源代码的读者来说更是如此：你自己。一两年后回来看看。。。如果您只讨论使用名称空间std；你可能不知道你抓取的所有内容——当你添加另一个#include或移动到一个新的C++修订版时，你可能会遇到你不知道的名称冲突。

您可以在本地使用

继续，在本地（几乎）自由使用它。当然，这可以防止你重复std:：--，重复也是不好的。

本地使用它的习惯用法

在C++03中，有一种习惯用法——样板代码——用于为类实现交换函数。有人建议您实际使用本地using命名空间std；--或至少使用std:：swap；：

class Thing {
    int    value_;
    Child  child_;
public:
    // ...
    friend void swap(Thing &a, Thing &b);
};
void swap(Thing &a, Thing &b) {
    using namespace std;      // make `std::swap` available
    // swap all members
    swap(a.value_, b.value_); // `std::stwap(int, int)`
    swap(a.child_, b.child_); // `swap(Child&,Child&)` or `std::swap(...)`
}

这有以下魔力：

编译器将为value_选择std:：swap，即void std:：swap（int，int）。如果实现了重载void swap（Child&，Child&），编译器将选择它。如果没有重载，编译器将使用void std:：swap（Child&，Child&），并尽可能地交换这些。

对于C++11，没有理由再使用这种模式了。对std:：swap的实现进行了更改，以找到一个潜在的过载并选择它。

这都是关于管理复杂性的。使用名称空间会将您不想要的东西拉进来，因此可能会使调试变得更困难（我说可能）。到处使用std:：很难阅读（更多的文本等等）。

马的课程-管理你的复杂性，尽你最大的能力和感觉。

有经验的程序员使用任何解决他们问题的方法，避免任何产生新问题的方法。出于这个确切的原因，他们避免使用头文件级别的指令。

经验丰富的程序员也尽量避免在源文件中使用完全限定的名称。这样做的一个次要原因是，除非有充分的理由，否则在代码较少的情况下编写更多的代码是不优雅的。一个主要原因是关闭参数依赖查找（ADL）。

这些好理由是什么？有时程序员明确希望关闭ADL，有时他们希望消除歧义。

因此，以下内容是可以的：

函数级使用指令并在函数的实现中使用声明使用源文件内声明的源文件级别（有时）使用指令的源文件级别