以C开头的类名

Question

MFC具有以C开头的所有类名。例如，CFile和CGdiObject。有没有人看过它在别处使用过？是否有Microsoft的官方命名约定指南推荐此样式？这个想法是源于MFC还是其他项目？

Answer 1

这是邪恶的。除了抽象的东西之外，不要使用匈牙利表示法。

例如，btnSubmit可以描述名为Submit的按钮（按钮旁边的标签会附带lblSubmit）

但类似于CMyClass的类和uiCount这样的无符号整数命名计数不会对程序员有帮助，只会导致额外的浪费。

Answer 2

在Symbian C ++中使用了类似的东西，其惯例是：

T类是“值”，例如TChar，TInt32，TDes

R类是内核（或其他）资源的句柄，例如RFile，RSocket

M类是mixins，其包括接口（被解释为没有函数实现的mixins）。指南是多重继承最多应包含1个非M类。

C类几乎是其他所有东西，并且来自CBase，它有一些东西可以帮助处理资源。

HBufC主要用于在Symbian论坛上生成混乱的帖子，拥有自己的前缀只是一个开始。 H代表“嗯？”，或者可能是“Haw，haw！你没有STL！” ; - ）

这与Apps Hungarian Notation而非匈牙利系统符号的精神非常接近。前缀告诉你一些关于你可以在文档中查找的类，但是你不会知道。 在编程中命名任何东西的重点是提供这样的提示和提醒，否则你只需要调用你的类“Class001”，“Class002”等。

系统匈牙利语只是告诉你一个变量的类型，IMO没什么好兴奋的，特别是像C ++这样的语言，其中类型往往不断重复或者完全被模板参数隐藏。它在命名类型时的类比是用I命名所有接口的Java实践。再一次，我对此并不感到兴奋（标准Java库也没有），但是如果你要为每个类定义一个接口，除了在非测试情况下实际用于多态的接口之外，你还需要一些方法来区分这两种接口。

Answer 3

这是一种旧的C ++编码风格，MFC可能是最后使用它的东西之一。

它通常只是C ++的惯例（也许还有其他几种语言），因此随着语言变得更具互操作性，它开始失宠，通过COM和.NET。

你仍然会看到它的表兄，接口的“I”前缀，很多时候。我总是觉得有趣的是“我”在“C”死亡时幸存下来，但这可能是因为接口在COM互操作性中被大量使用。

Answer 4

我记得Borland的编译器带着库，其中的类名以'T'开头。可能是“类型”：）

Answer 5

多年前，命名约定对于帮助识别类，甚至是类的分组类型至关重要。不要忘记当时没有名称空间，也没有/有限的intellisense可用。 C是匈牙利符号的一种形式，但肯定受到MFC的欢迎。 Borland和Delphi使用T - 作为Type

的前缀

Answer 6

虽然MFC和许多为Windows编写的软件都使用了类的“C”约定，但通常在为UNIX平台编写的软件中找不到后者。我认为这是Visual C ++非常强烈鼓励的习惯。我记得Visual C ++ 6.0会在“C”前面加上用类向导创建的任何类。

Answer 7

我无法回答你的所有问题，但据我所知，这只是将MFC类与其他类区分开来 - 一种匈牙利符号。

有趣的是，它显然不仅仅是在MS之外引起争议，而是inside as well。

Answer 8

请参阅此处：http://www.jelovic.com/articles/stupid_naming.htm，了解有关此问题的长篇文章。

Answer 9

我们在工作中使用它，就像许多其他命名约定一样

很多我的意思是C代表类，p代表指针，m_代表成员，s_代表静态成员，n代表整数...不是很多文档

Answer 10

这些变量约定对于像Fortran这样的语言很有用，在使用它们之前不需要声明变量的类型。我似乎记得那些名字以“i”或“j”开头的变量默认为整数，变量的名字以“r”开头，其他字母默认为真实（浮动）值。

人们对你需要声明变量的语言使用类似的东西 - 或者对于类定义 - 可能只是某些人误解了Fortran等语言的旧代码约定的遗留物。

Answer 11

在编写使用Qt库的应用程序时，我们使用命名约定来区分直接或间接从QObject派生的类与不是QST的类。这很有用，因为你可以从类名中知道它是否支持信号/插槽，属性以及来自QObject的所有其他好东西。