Class names that start with C

Question

The MFC has all class names that start with C. For example, CFile and CGdiObject. Has anyone seen it used elsewhere? Is there an official naming convention guide from Microsoft that recommends this style? Did the idea originate with MFC or was it some other project?

Answer 1

we use it at work, like many other naming conventions

by many I meant C for classes, p for pointer, m_ for members, s_ for static members, n for integer ... not many documents

Answer 2

While MFC and lots of software written for Windows used the "C" convention for classes, you generally don't find the latter in software written for UNIX platforms. I think it was a habit very strongly encouraged by Visual C++. I remember that Visual C++ 6.0 would prefix a "C" to any classes that one created with the class wizard.

Answer 3

Such conventions for variables are useful for languages like Fortran where you don't need to declare the types of your variables before using them. I seem to recall that variables who's names started with "i" or "j" defaulted to integers, and variables who's names started with "r" and other letters defaulted to real (float) values.

That people use similar for languages where you do need to declare variables - or for class definitions - is probably just a relic of someone misunderstanding the old code conventions from languages like Fortran where it actually mattered.

Answer 4

personally I find that hungarian notation helps me, in that I can look at a screen full of variables and instantly know what they are as I try and absorb the logic. Your only argument against it I see is "extra typing"

Answer 5

It's evil. Don't use Hungarian Notation for anything but abstracted things.

For instance, btnSubmit is ok to describe a button named Submit(which would have an accompanying lblSubmit for the label next to the button)

But things like CMyClass for Class and uiCount for unsigned integer named count does not help programmers and just leads to extra wasteful typing.

Answer 6

When writing applications that use the Qt libraries, we use a naming convention that distinguishes classes that are directly or indirectly derived from QObject from classes that aren't. This is useful because you can tell from the class name whether or not it supports signals/slots, properties, and all the other goodies that come from QObject.