我同意不应该在全球范围内使用它，但在本地使用它并没有那么糟糕，就像在命名空间中一样。下面是“C++编程语言”中的一个示例：

namespace My_lib {

    using namespace His_lib; // Everything from His_lib
    using namespace Her_lib; // Everything from Her_lib

    using His_lib::String; // Resolve potential clash in favor of His_lib
    using Her_lib::Vector; // Resolve potential clash in favor of Her_lib

}

在本例中，我们解决了由它们的组合引起的潜在名称冲突和歧义。

在那里显式声明的名称（包括通过使用His_lib:：String等声明声明的名称）优先于通过using指令（使用名称空间Her_lib）在另一个作用域中可访问的名称。

是的，名称空间很重要。在我的项目中，我需要将一个var声明导入到源代码中，但在编译时，它与另一个第三方库冲突。

最后，我不得不用其他方法来解决这个问题，并使代码变得不那么清晰。

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

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

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

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

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

很高兴看到代码并知道它做什么。如果我看到std:：cout，我知道这是std库的cout流。如果我看到cout，我不知道。它可能是std库的cout流。或者有一个int cout=0；在同一函数中高出十行。或该文件中名为cout的静态变量。它可能是任何东西。

现在以一百万行代码库为例，它不是特别大，你正在搜索一个bug，这意味着你知道在这一百万行代码中有一行没有完成它应该做的事情；可以读取名为cout的静态int，将其向左移动一位，然后丢弃结果。要找bug，我必须检查一下。你能看出我真的更喜欢看std:：cout吗？

如果你是一名教师，并且从未以编写和维护代码为生，那么这是一个非常好的主意。我喜欢看到代码：（1）我知道它做什么；而且，（2）我相信写它的人知道它的作用。

它不会使您的软件或项目性能更差。在源代码开头包含名称空间还不错。using namespace std指令的包含根据您的需求以及开发软件或项目的方式而有所不同。

命名空间std包含C++标准函数和变量。当您经常使用C++标准函数时，这个名称空间非常有用。

如本页所述：使用命名空间std的语句通常被认为是错误的实践此语句的替代方法是指定使用作用域运算符（：：）将标识符所属的命名空间每次我们声明一个类型。请参阅以下意见：在源文件中使用“using namespace std”没有问题当您大量使用命名空间并确信任何东西都不会碰撞。

有些人曾说过，在源文件中包含using命名空间std是一种不好的做法，因为您正在从该命名空间调用所有函数和变量。当您想定义一个与命名空间std中包含的另一个函数同名的新函数时，您会重载该函数，因为编译或执行可能会产生问题。它不会像您期望的那样编译或执行。

如本页所述：尽管该语句使我们不必在任何时候输入std:：我们希望访问std命名空间中定义的类或类型将整个std命名空间导入当前命名空间该计划的一部分。让我们举几个例子来理解为什么可能不是什么好事...现在，在开发的后期阶段，我们希望使用cout是在某个名为“foo”的库中自定义实现的（用于示例）...注意这里有一个歧义，cout指向哪个库？编译器可能会检测到这一点，而不会编译程序。在最坏的情况下在这种情况下，程序仍可能编译，但调用了错误的函数，因为我们从未指定标识符属于哪个命名空间。

这是一种糟糕的做法，通常被称为全局命名空间污染。当多个名称空间具有相同的函数名和签名时，可能会出现问题，那么编译器决定调用哪个名称空间是不明确的，当您使用std:：cout这样的函数调用指定名称空间时，这一切都可以避免。希望这有帮助。：）