C++ 中的变量命名约定

匈牙利语表示法在 Win32 和 MFC API 的用户中很常见。如果你的前辈正在使用它，你最好继续使用它（即使它很糟糕）。C++ 世界的其他部分从未有过这种脑死亡约定，所以如果你使用的是这些 API 以外的东西，请不要使用它。

这种匈牙利符号是相当无用的，如果你必须改变某样东西的类型，可能比无用更糟糕。（正确的匈牙利符号是另一回事。

我建议你使用你的团队所做的任何事情。如果您是唯一参与该计划的人，请以对您最有意义的方式命名它们。

我认为您仍然会发现大多数使用 Visual C++ 编程的商店都坚持使用匈牙利符号，或者至少是它的淡化版本。在我们的商店中，我们应用程序的一半是旧版 C++，顶部有一个闪亮的新 C# 层（中间有一个托管的 C++ 层）。我们的 C++ 代码继续使用匈牙利语表示法，但我们的 C# 代码使用您介绍的表示法。我认为它很丑陋，但它是一致的。

我说，在你的项目中使用你的团队想要的任何东西。但是，如果您正在处理遗留代码或加入团队，请坚持使用现有的风格以保持一致性。

最重要的是要保持一致。如果使用的是旧代码库，请按照旧代码的命名约定一致地命名变量和函数。如果您编写的新代码仅与旧代码交互，请在新代码中使用命名约定，但也要与自己保持一致。

我同意这里的其他答案。为了保持一致性，要么继续使用流传下来的风格，要么想出一个适合你的团队的新约定。团队达成一致很重要，因为几乎可以保证您将更改相同的文件。话虽如此，我过去发现一些事情非常直观：

类/结构成员变量应该突出 - 我通常以m_为前缀
全局变量应该突出 - 通常以g_
为前缀 变量通常应以小写开头 函数名称通常应以大写

开头 宏和可能的枚举应全部大写
所有名称都应描述函数/变量的作用，而不应描述其类型或值。

在这个例子中，除了有点丑陋之外，还有什么不喜欢或嘲笑“ppMyObjects”的呢？无论哪种方式，我都没有强烈的意见，但它确实一目了然地传达了有用的信息，而“MyObjects”则没有。

我自己就是一个匈牙利符号的人，因为我发现它为代码提供了可读性，而且我更喜欢自记录代码而不是注释和查找。

也就是说，我认为你可以为了团队的团结而牺牲你喜欢的风格和一些额外的可维护性。我不相信为了统一代码可读性而保持一致性的论点，特别是如果你为了一致性而降低可读性......这根本没有意义。但是，与你一起工作的人相处在一起，可能值得在查看变量的类型上多混淆一下。

这完全取决于个人喜好。我曾在 2 家公司工作过，这两家公司都有类似的计划，其中成员 var 被命名为 m_varName。我从未见过在工作中使用匈牙利符号，而且真的不喜欢它，但又归结为偏好。我的总体感觉是IDE应该负责告诉你它是什么类型，所以只要名称足以描述它的作用（m_color，m_shouldBeRenamed），那就没关系了。我喜欢的另一件事是成员变量、局部 var 和常量命名之间的差异，因此很容易看到函数中发生了什么以及 var 来自哪里。 成员： m_varName 常量：c_varName 本地：varName

不。 “错误的匈牙利语符号”——尤其是双间接的 pp——对于早期的 C 编译器来说是有一定道理的，因为你可以编写

int * i = 17;
int j = ***i;

甚至没有来自编译器的警告（这甚至可能是正确硬件上的有效代码......

“真正的匈牙利符号”（由 head Geek 链接）仍然是 IMO 的有效选择，但不一定是首选。现代 C++ 应用程序通常有数十或数百种类型，您找不到合适的前缀。

在少数情况下，我仍然在本地使用它，例如，在问题域中具有非常相似甚至相同名称的整数和浮点变量，例如

float fXmin, fXmax, fXpeak; // x values of range and where y=max
int   iXmin, iXMax, iXpeak; // respective indices in x axis vector

---

但是，在维护始终遵循某些约定（即使松散）的遗留代码时，您应该坚持使用那里的约定 - 至少在要维护的现有模块/编译单元中。

我的理由是：编码标准的目的是遵守最小意外原则。始终如一地使用一种样式比使用哪种样式更重要。

如果使用 CamelCase，则约定是将第一个字母大写 对于类、结构和非基元类型名称，以及小写的第一个字母，表示数据成员。 方法的大写往往是一个混合包，我的方法往往是动词，并且已经被括号所困扰，所以我不大写方法。

就我个人而言，我不喜欢阅读 CamelCase 代码，更喜欢下划线小写 数据和方法标识符，将类型大写，并为首字母缩略词保留大写字母 以及我使用宏的罕见情况（警告这是一个宏）。

我也更喜欢CamelCase，事实上，我见过大多数人在C++中使用CamelCase。就个人而言，我不对私有/受保护的成员和接口使用任何前缀：

class MyClass : public IMyInterface {
public:
    unsigned int PublicMember;
    MyClass() : PublicMember(1), _PrivateMember(0), _ProtectedMember(2) {}
    unsigned int PrivateMember() {
        return _PrivateMember * 1234; // some senseless calculation here
    }
protected:
    unsigned int _ProtectedMember;
private:
    unsigned int _PrivateMember;
};
// ...
MyClass My;
My.PublicMember = 12345678;

为什么我决定省略公共成员的前缀：因为公共成员可以像在结构中一样直接访问，并且不会与私有名称冲突。除了使用下划线，我还看到人们使用第一个小写字母来表示成员。

struct IMyInterface {
    virtual void MyVirtualMethod() = 0;
};

根据定义，接口仅包含需要稍后实现的纯虚拟方法。然而，在大多数情况下，我更喜欢抽象类，但这是另一回事了。

struct IMyInterfaceAsAbstract abstract {
    virtual void MyVirtualMethod() = 0;
    virtual void MyImplementedMethod() {}
    unsigned int EvenAnPublicMember;
};

请参阅高完整性 C++ 编码标准手册以获取更多灵感。

我的团队遵循以下 Google C++ 代码约定：

这是变量名称的示例：

string table_name;  // OK - uses underscore.
string tablename;   // OK - all lowercase.

string tableName;   // Bad - mixed case.