Question

我来自.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

谢谢！

Answer 1

这种匈牙利符号是相当无用的，如果你必须改变某种类型，可能比无用更糟糕。（The proper kind of Hungarian Notation是另一回事。）

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

Answer 2

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

Answer 3

没有。 “错误的匈牙利符号” - 尤其是双重间接的pp - 对于你可以编写的早期C编译器来说是有道理的

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

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

“真正的匈牙利符号”（由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

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

我的理由：编码标准的目的是遵循最少惊喜的原则。始终如一地使用一种风格比使用哪种风格更重要。

Answer 4

除了有点丑陋之外，在这个例子中有什么不喜欢或嘲笑“ppMyObjects”？我没有强烈的意见，但它确实传达了有用的信息，“MyObjects”没有。

Answer 5

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

类/结构成员变量应该突出 - 我通常在它们前面添加m_
全局变量应该突出 - 通常使用g_
的前缀一般变量应从小写字母开始功能名称一般应以大写字母
开头宏和可能的枚举应该是大写的所有名称都应描述函数/变量的作用，并且不应描述其类型或值。

Answer 6

我自己是一个匈牙利记谱员，因为我发现它为代码提供了可读性，而且我更喜欢自我记录代码来评论和查找。

那就是说，我认为你可以为牺牲自己喜欢的风格和团队合作的一些额外可维护性做出判断。为了统一的代码可读性，我不会购买一致性的论点，特别是如果你的可读性降低可靠性......它只是没有意义。但是，与你一起工作的人相处可能会对看变量的类型更加困惑。

Answer 7

匈牙利表示法在Win32和MFC API的用户中很常见。如果您的前任使用它，您可能最好继续使用它（即使它很糟糕）。其余的C ++世界从未有过这种脑死亡的惯例，所以如果你使用的不是那些API，就不要使用它。

Answer 8

我认为您仍然会发现大多数使用Visual C ++编程的商店都使用匈牙利语符号或者至少有一个淡化版本。在我们的商店中，我们的应用程序的一半是遗留的C ++，顶部有一个闪亮的新C＃层（中间有一个托管的C ++层。）我们的C ++代码继续使用匈牙利语表示法，但我们的C＃代码使用了你所呈现的符号。我觉得它很难看，但它是一致的。

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

Answer 9

一切都取决于个人喜好。我曾为2家公司工作，这两家公司都有类似的方案，其中成员变量被命名为m_varName。我从未在工作中看到过使用过的匈牙利符号，并且真的不喜欢它，但是再次归结为偏好。我一般认为IDE应该注意告诉你它是什么类型，所以只要名称足够描述它的作用（m_color，m_shouldBeRenamed），那就没问题。我喜欢的另一件事是成员变量，局部变量和常量命名之间的区别，因此很容易看出函数中发生了什么以及变量来自何处。成员：m_varName Const：c_varName local：varName

Answer 10

我也更喜欢CamelCase，实际上我见过人们在C ++中使用CamelCase。 Personaly我不会使用私有/受保护成员和接口的任何前缀：

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;
};

请参阅High Integrity C++ Coding Standard Manual获取更多灵感。

Answer 11

我们的团队使用Google C++ code convention：

这是变量名称的示例：

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

string tableName;   // Bad - mixed case.

Answer 12

如果您使用CamelCase，则约定是将首字母大写类结构和非基本类型名称，小写是数据成员的第一个字母。方法的资本化往往是一个混合的包，我的方法往往是动词，并且已经由parens distished所以我没有资本化方法。

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

C ++中的变量命名约定

12 个答案: