可能以下划线开头的变量/成员会困扰编译器吗？

从高中开始我就被教导要定义如下变量：

int _a;

要么

int __a;

应该将其视为不良做法，因为这最终会使使用下划线开头的变量来命名临时变量的编译器感到困惑。

据我所知，这就是有些人喜欢在名称末尾移动下划线的原因，例如：

int a_;

但是，我看到很多代码都使用下划线开头的变量。而且该代码在Visual Studio 2010和g ++ 4.x中都可以很好地构建。

所以我想知道：这今天不是问题吗？现代编译器在命名约定方面更聪明吗？

您显然误会了前缀下划线是不良做法的原因。简而言之，这是因为C和C ++标准将这些前缀保留用于实现细节，例如用于标准库实现。（请注意，_和__并非为相同的内容保留，请参见注释）

即使名称在范围内（名称空间，类等），也可能存在一些全局名称，尤其是宏，它们使用这些前缀，并且如果也使用它们，可能会无声地破坏您的代码。

因此，基本上，在大多数情况下，如果不使用这些前缀BUT，则可以安全使用，您可以100％保证命名不会与实现名称冲突。

这就是为什么毫无疑问不使用这些前缀的原因。

使用两个下划线绝对是不好的-保留给特定于编译器的实现细节。这不适用于使用一个下划线。

有些人讨厌下划线。不管你叫什么m_index或highest_price或_a-他们厌恶它。我与25年前的某人一起工作，他告诉我一台特定的IBM打印机（一种非常受欢迎的打印机），通过省略每行的底部像素，该打印机可以在页面上容纳更多行。这对于便笺或大量数字等的输出是很好的，但是对于使下划线的一半不可见的代码有效。（是的，真的！）这一代人通常会产生不合理的下划线仇恨，这可能是由于与该打印机的交互作用，或者是因为与不使用下划线的人打交道。

使用混合大小写（选项我们没有在，说，Fortran）编写一个更可读的方式大多数人认为：mIndex，HighestPrice，a站起来相当不错早前下划线的例子。我给你两个规则：

• 永远不要用两个下划线启动任何东西（函数，变量，宏，typedef）
• 选择一个一致的约定（例如，_limit对于函数参数，m_limit对于成员变量，切勿使用下划线，驼峰式大小写，每个词都要大写，匈牙利语，诸如此类）并坚持使用。有时不要以下划线开头，有时结尾，有时不使用下划线以及五种不同的大小写约定。始终如一。

有问题的打印机早已不复存在。如果您想一次使用一个下划线，请随时使用。但请理解，下划线仇恨仍然存在。