37

我来自 .NET 世界，并且是编写 C++ 的新手。我只是想知道在命名局部变量和结构成员时首选的命名约定是什么。

例如，我继承的遗留代码有很多：

struct MyStruct
{
   TCHAR           szMyChar[STRING_SIZE];
   bool            bMyBool;
   unsigned long   ulMyLong;
   void*           pMyPointer;
   MyObject**      ppMyObjects;
}

来自 C# 背景的我很震惊地看到带有匈牙利符号的变量（我第一次看到 pp 前缀时就忍不住笑了）。

我宁愿以这种方式命名我的变量（尽管我不确定首字母大写是否是一个好的约定。我见过其他方式（见下面的链接））：

struct MyStruct
{
   TCHAR           MyChar[STRING_SIZE];
   bool            MyBool;
   unsigned long   MyLong;
   void*           MyPointer;
   MyObject**      MyObjects;
}

我的问题：这（前一种方式）是否仍然是在 C++ 中命名变量的首选方式？

参考：

http://geosoft.no/development/cppstyle.html

http://www.syntext.com/books/syntext-cpp-conventions.htm

http://ootips.org/hungarian-notation.html

谢谢！

4

12 回答 12

61

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

我建议你使用你的团队所做的任何事情。如果您是该程序的唯一工作人员，请以对您最有意义的方式命名。

于 2008-10-24T19:07:42.033 回答
17

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

于 2008-10-24T19:08:41.233 回答
15

不，“错误的匈牙利表示法”——尤其是用于双重间接的 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

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

我的推理：编码标准的目的是遵守最小意外原则。始终使用一种风格比使用哪种风格更重要。

于 2008-10-24T22:02:05.457 回答
5

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

于 2008-10-24T19:23:34.450 回答
3

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

类/结构成员变量应该突出 - 我通常以 m_ 为前缀
全局变量应该突出 - 通常以 g_ 为前缀
变量通常应以小写
函数开头通常名称应以大写
宏开头，并且可能枚举应全部大写
所有名称都应该描述函数/变量的作用，并且永远不应该描述它的类型或值。

于 2008-10-24T19:16:28.520 回答
2

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

也就是说，我认为您可以为牺牲自己喜欢的风格和一些额外的可维护性以实现团队团结提出理由。为了统一的代码可读性，我不购买一致性的论点，特别是如果你为了一致性而降低可读性......它只是没有意义。但是，与您一起工作的人相处可能值得在查看变量的类型上多加混淆。

于 2008-10-24T19:43:42.647 回答
1

匈牙利符号在 Win32 和 MFC API 的用户中很常见。如果您的前任正在使用它，您最好继续使用它（即使它很烂）。C++ 世界的其他地方从来没有过这种脑残的约定，所以如果你使用的是那些 API 以外的东西，就不要使用它。

于 2008-10-24T19:06:51.520 回答
1

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

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

于 2008-10-24T19:08:18.193 回答
1

这完全取决于个人喜好。我曾为 2 家具有类似方案的公司工作，其中成员变量被命名为 m_varName。我从未见过在工作中使用匈牙利符号，并且真的不喜欢它，但又归结为偏好。我的一般感觉是 IDE 应该注意告诉你它是什么类型，所以只要名称足以描述它的作用（ m_color, m_shouldBeRenamed ），就可以了。我喜欢的另一件事是成员变量、局部变量和常量命名之间的区别，因此很容易看出函数中发生了什么以及变量来自哪里。成员：m_varName 常量：c_varName 本地：varName

于 2008-10-24T19:44:11.350 回答
1

我也更喜欢 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++ 编码标准手册。

于 2012-05-15T12:55:43.717 回答
1

我的团队遵循这个Google C++ 代码约定：

这是变量名称的示例：

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

string tableName;   // Bad - mixed case.
于 2014-01-20T05:17:54.370 回答
0

如果您使用 CamelCase，约定是类结构和非原始类型名称的首字母大写，数据成员的首字母小写。方法的大写往往是一个混合包，我的方法往往是动词，并且已经被括号区分，所以我不大写方法。

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

于 2008-12-20T21:12:34.497 回答