以C开头的类名

Symbian C++中有一些类似的东西,其中的约定是:

t类是“值”,例如tchar、tint32、tdes

R类是内核(或其他)资源的句柄,例如rfile、rsocket

M类是mixin,它包括接口(被解释为不带函数实现的mixin)。指导原则是多重继承最多应涉及1个非m类。

C类几乎是所有其他的东西,并且派生自cbase,cbase中有一些东西可以帮助处理资源。

hbufc的存在主要是为了在Symbian论坛上生成混乱的帖子,而拥有自己的前缀只是一个开始。H代表“啊?”或者可能是“啊,啊!你没有STL!”;-)

这在精神上接近应用匈牙利符号,而不是系统匈牙利符号。前缀告诉您一些关于类的信息,您可以在文档中查找这些信息,但是您不知道这些信息。 在编程中命名任何东西的关键是提供这样的提示和提醒 否则你只需要把你的课程叫做“Class001”、“Class002”等。

匈牙利系统只是告诉你一个变量的类型,IMO没有什么值得兴奋的,尤其是在C++之类的语言中,这些类型经常被重复地重复,或者完全被模板参数所隐藏。在命名类型时,它的类比是用I.再次命名所有接口的Java实践,对此我并不感到非常兴奋(标准Java库也没有),但是如果您要为每个类定义一个接口,除了在非测试情况下实际用于多态性的接口之外,那么您还需要一些W。可以区分这两个。

这是邪恶的。除了抽象的东西外,什么都不要用匈牙利符号。

例如, btnSubmit 是否可以描述一个名为Submit的按钮(该按钮将带有 lblSubmit 按钮旁边的标签)

但像 CMyClass 为了班级和 uiCount 对于无符号整数,count不帮助程序员,只会导致额外的浪费性输入。

这是一个古老的C++编码风格,MFC可能是最后一个使用它的东西。

它通常只是C++的一个约定(也许还有一些其他语言),因此它开始变得不受欢迎,因为语言变得更可互操作,通过COM和.NET。

你仍然可以看到它的表亲,接口的“i”前缀,经常出现。我一直觉得有趣的是,“c”死后,“i”幸存了下来,但这可能是因为接口在COM互操作性中被大量使用。

我记得Borland的编译器曾与类名以“t”开头的图书馆合作过。可能是“type”:)

几年前,命名约定对于识别类、甚至类的分组都是至关重要的。别忘了当时没有命名空间,也没有/有限的IntelliSense可用。C是匈牙利符号的一种形式,但肯定会受到MFC的欢迎。Borland和Delphi使用t-作为类型的前缀

虽然MFC和许多为Windows编写的软件使用类的“C”约定,但通常在为UNIX平台编写的软件中找不到后者。我认为这是一个深受VisualC++鼓励的习惯。我记得VisualC++ 6会把一个“C”前缀到一个用类向导创建的类中。

我不能回答你所有的问题,但据我所知,这只是区分MFC类和其他类——匈牙利符号的一种形式。

有趣的是,这显然是有争议的,不仅仅是在微软之外,而是 inside as well .

请参见这里: http://www.jelovic.com/articles/stupid_naming.htm 关于这个问题的长篇文章。

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

人们在需要声明变量的语言或类定义中使用类似的语言,这可能只是某些人从实际重要的语言(如Fortran)误解了旧的代码约定的遗留问题。

在编写使用Qt库的应用程序时,我们使用一种命名约定,将直接或间接从QObject派生的类与非QObject派生的类区分开来。这很有用,因为可以从类名中分辨出它是否支持信号/槽、属性以及所有其他来自QObject的优点。

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

我的意思是C代表类,P代表指针,M代表成员,S代表静态成员,N代表整数…文件不多

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