在C++中命名 int 或 char 变量时，"n"或"ch"前缀是通用前缀吗？

Are "n" or "ch" prefixes common prefixes when naming int or char variables in C++?

本文关键字：前缀 ch C++ int 变量 char      更新时间：2023-10-16

我目前正在学习learncpp.com的C++教程，我看到他们的变量命名趋势是用"n"前缀（即int nValue）和"ch"前缀来命名int变量（即char chOperation）。这是行业中常见的事情吗？我现在应该养成这种习惯？

这在业内是司空见惯的事吗？

这种做法在二三十年前的微软某些部门很常见，因为人们误解了公司其他部门使用的一种更有用的约定（标记变量的约定表明了它们的目的，在弱类型语言中，这有助于避免各种类别错误）。在像C++这样的强类型语言中，这两种约定都没有任何有用的用途：类型系统可以更可靠地自动捕获此类错误。

早在微软（大概）意识到它毫无意义并建议不要使用它之后，它就被其他人广泛使用了，大概是因为微软相信模仿微软的习惯也可能效仿他们的成功。如今，养成习惯、从不质疑其有用性的人，以及将风格指南置于软件之上的公司，仍然偶尔会看到这种情况。

就我个人而言，我发现这是一个有用的警告，即代码可能包含更糟糕的恐怖。

我现在应该养成一种习惯吗？

它只会使代码更难阅读，如果您在更改变量类型时忘记更新标记，则会产生误导。你应该养成一个习惯，写清楚可读的代码，而不是在上面撒上神秘的符文。

免责声明：关于微软的简短评论旨在提供历史背景，而不是对微软政策决定的授权说明；特别是"[Microsoft]意识到[它]毫无意义"这句话的意思是"[微软的一些人]意识到（正在讨论的话题，在大多数情况下在现代C++中使用冗余类型标签）毫无意义"，而不是（正如一位评论者所读到的）"[整个微软]意识到所有变量标签的使用都毫无意义"。所有的观点都是我自己的，可能都是基于不完善的知识

是的，它们很常见（尤其是在与Windows相关的项目中）

但是不同的项目可能使用不同的编码风格。因此，如果你正在处理一个现有的项目，那么最好的办法就是坚持它已经遵循的风格。

您提到的命名风格被称为匈牙利风格，通常用于与Windows相关的项目。在匈牙利风格中，变量的格式为驼色大小写（例如CamelCase），并以其范围和类型作为前缀：

[scope prefix]_[variable type][actual variable name in camel-cased style]

例如：

m_nMemberInteger

是一个整数（根据其前缀n），此外，它是某个结构/类的成员变量（根据其后缀m_），您可以在上面的链接中找到匈牙利风格中使用的范围和类型前缀的完整列表。

然而，在基于linux的项目中，你通常会发现人们使用不同的编码风格（例如。，Google c++编码风格），只使用小写和下划线_来命名变量。

这看起来类似于匈牙利符号。这样的东西有时会被使用，尤其是在某些编程领域。就我个人而言，我认为这会让代码看起来一团糟。在C++中，你应该更多地考虑对象的含义，而不是它的底层类型。现代编辑器可以让你很容易地查找变量的类型，所以它有点过时了。我能理解为什么在编辑没有那么大帮助的情况下使用它。。

如其他注释中所述，这被称为"匈牙利符号"，用于使变量的类型显而易见。虽然标记类型是否值得麻烦可能存在争议，但另一种常见的约定（尤其是在C++中）是使用前缀来指示有关变量用法的信息。这对于引用和成员变量特别有用。例如，一个可能有一个看起来像的函数

void MyClass::myMethod(const int& iInput, int& oOutput, int &ioInputAndOutput)
{
    oOutput = ioInputAndOutput + mMemberData + iInput;
    ioInputAndOutput *= 2; 
}

如上所述，重要的是一致性，这将比任何特定的约定都能防止更多的错误。在合作项目中，遵守现有惯例通常是值得的。

相关文章：