以 C 开头的类名答案

【问题标题】：Class names that start with C以 C 开头的类名
【发布时间】：2011-01-18 13:06:35
【问题描述】：

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

【问题讨论】：

我所知道的是，我很高兴他们使用 .NET 命名约定修复了它 :)

标签： c++ visual-c++ mfc hungarian-notation

【解决方案1】：

这是邪恶的。除了抽象的东西，不要使用匈牙利符号。

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

但是像 CMyClass 用于 Class 和 uiCount 用于名为 count 的无符号整数对程序员没有帮助，只会导致额外的浪费输入。

【讨论】：

@Habi：在这种情况下，您可能更愿意听编译器警告。此外，也许使用更具描述性的变量名称 - 通用 x 坐标应该是无符号的原因是什么？
@Habi：当uiCount 的类型从unsigned int 更改为unsigned long、signed int 或double 时会发生什么？根据匈牙利表示法，变量必须重命名，在任何地方使用它。根据验证，任何修改的功能或方法都必须经过测试。看起来像是完整回归测试的开始。 :-(
@UncleBens：我认为如果使用得当，匈牙利符号 (HN) 会很有用。在代码审查和代码前分析期间，听取编译器警告并没有帮助。特别是嵌入式系统的编译器在这一点上相当薄弱。我知道至少有一个编译器在这种情况下即使在最高警告级别也不会发出警告。好吧，你是对的，给定的例子不是最好的。尽管如此，我还是喜欢通过阅读代码即时查看变量的类型。额外的输入是反对 HN 的最弱论据。
@Thomas M.：你是对的，你必须测试使用变量的代码。但是不管有没有 HN（匈牙利符号），你都必须这样做。由于您必须在任何地方更改命名，您就知道要测试什么。这是 HN 的最大优势之一，也是我们使用它的主要原因。我们正在开发医疗设备。在不检查影响变量的情况下更改变量的类型确实不是一个好主意，不仅仅是医疗设备。如果您更改类型，HN 至少会强制您查看变量的使用位置。
良好的匈牙利符号可以有一些模糊的方便用途，例如 DIY 污点检查。例如，您可以使用 Apps Hungarian 在“安全”（通常是指经过清理和/或转义）字符串和“不安全”字符串之间划定界限：uName 是来自用户输入的未经检查的名称，sName 是安全的名称，uGetName 返回未经检查的字符串，sGetName 返回安全字符串。 char * sEscape(char *uName) 清洗字符串。方便的部分是您从不将名为u 的变量传递给带有名为s 的参数的函数。当然，并不总是值得付出努力。

【解决方案2】：

在 Symbian C++ 中使用了一些类似的东西，其中的约定是：

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

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

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

C 类几乎是其他所有东西，并且从 CBase 派生，其中包含一些有助于资源处理的东西。

HBufC 的存在主要是为了在 Symbian 论坛上生成混乱的帖子，拥有自己的前缀只是开始。 H 代表“嗯？”，或者可能是“哇，哇！你没有 STL！” ;-)

这在精神上接近于 Apps Hungarian Notation，而不是 Systems Hungarian notation。前缀告诉您有关该类的一些信息，您可以在文档中查找这些信息，但您不知道这些信息。 在编程中命名任何东西的全部意义在于提供这样的提示和提醒，否则你只需将你的类称为“Class001”、“Class002”等。

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

【讨论】：

【解决方案3】：

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

它通常只是 C++（可能还有其他几种语言）的约定，因此随着语言变得更加可互操作，通过 COM 和 .NET，它开始失宠。

您仍然经常看到它的表亲，即接口的“I”前缀。我一直觉得有趣的是，当“C”死亡时，“I”幸存下来，但这可能是因为接口在 COM 互操作性中被大量使用。

【讨论】：

我认为清楚地传达一个事实很重要，即一个类应该是一个接口并且以I 为前缀可能仍然被广泛使用，因为它比Base 更短更清晰后缀。
它可能没有死，因为它解决了少数群体（接口、泛型类型参数）并且最常见的（类）不会变得杂乱无章。
那么还有谁用过它？只有微软？
常用于使用MFC/ATL/WTL的第三方代码中。顺便说一句，我相信最后一个使用这个约定的东西实际上是 WTL。许多 MS 代码也使用它 - 例如。看看转子。
@User1 - Borland 的 OWL 使用 T（我相信的类型）作为类名的前缀

【解决方案4】：

我记得 Borland 编译器使用类名以“T”开头的库。可能是“类型”:)

【讨论】：

我一直认为这是因为 Turbo Pascal/Turbo C 中的 T... 编码自恋 :)

【解决方案5】：

我不能回答你所有的问题，但据我所知，这只是为了将 MFC 类与其他类区分开来——匈牙利符号的一种形式。

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

【讨论】：

是的，他们知道什么 - .NET 指南（例如）拒绝为类添加前缀的想法，但对接口前缀很好。有时争论是没有充分理由的。

【解决方案6】：

多年前的命名约定对于帮助识别类、类型甚至是类的分组至关重要。不要忘记当时没有命名空间，也没有/有限的智能感知可用。 C 是匈牙利符号的一种形式，但肯定被 MFC 流行起来。 Borland 和 Delphi 使用 T - 作为 Type 的前缀

【讨论】：

另一种 MFC 设计选择基于二十年前 MS 编译器支持的内容，而不是现代 C++ 中的实现方式。

【解决方案7】：

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

【讨论】：

【解决方案8】：

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

【讨论】：

【解决方案9】：

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

人们在需要声明变量或类定义的语言中使用类似的方法，这可能只是有人误解了 Fortran 等语言的旧代码约定，而这实际上很重要。

【讨论】：

【解决方案10】：

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

【讨论】：

【解决方案11】：

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

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

【讨论】：

【解决方案12】：

就我个人而言，我发现匈牙利符号对我有帮助，因为我可以看着一个充满变量的屏幕，并在我尝试吸收逻辑时立即知道它们是什么。我看到你唯一反对它的论点是“额外输入”

【讨论】：