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?

Verine

All I know is that I'm glad they fixed it with .NET naming conventions :) – Halloran

Answer 1

Something a bit similar is used in Symbian C++, where the convention is that:

T classes are "values", for example TChar, TInt32, TDes

R classes are handles to kernel (or other) resources, for example RFile, RSocket

M classes are mixins, which includes interfaces (construed as mixins with no function implementations). The guideline is that multiple inheritance should involve at most 1 non-M class.

C classes are pretty much everything else, and derive from CBase, which has some stuff in it to help with resource-handling.

HBufC exists primarily to generate confused posts on Symbian forums, and having its very own prefix is just the start. The H stands for "huh?", or possibly "Haw, haw! You have no STL!" ;-)

This is close in spirit to Apps Hungarian Notation rather than Systems Hungarian notation. The prefix tells you something about the class which you could look up in the documentation, but which you would not know otherwise. The whole point of naming anything in programming is to provide such hints and reminders, otherwise you'd just call your classes "Class001", "Class002", etc.

Systems Hungarian just tells you the type of a variable, which IMO is nothing to get very excited about, especially in a language like C++ where types tend to be either repeated constantly or else completely hidden by template parameters. Its analogue when naming types is the Java practice of naming all interfaces with I. Again, I don't get very excited about this (and neither do the standard Java libraries), but if you're going to define an interface for every class, in addition to the interfaces which are actually used for polymorphism in non-test situations, then you need some way to distinguish the two.

Torment

Answer 2

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.

Behold

@Earlz: I don't agree with your statement about uiCount and extra typing. If I read something like "if ( uiXCoord < 0 )" a red light starts to blink, but not if I read "if ( xCoord < 0 )" and xCoord is an unsigend int. And typing some extra characters will never be a reason why a software is not ready in time, typing code is the smallest problem a software developer has. Knowing what to type is much more important. – Babbling

@Habi: In such situations you might rather want to listen to compiler warnings. Also, perhaps use more descriptive variable names - what's the reason a generic x coordinate should be unsigned? – Amourpropre

@Habi: What happens when the type changes for uiCount from an unsigned int to unsigned long, signed int or double? According to Hungarian Notation, the variable must be renamed, everywhere it is used. According to validation, any modified function or method must be tested. Looks like the start of complete regression testing. :-( – Bracteole

@UncleBens: My opinion is that the Hungarian Notation (HN) is useful if it is used advisedly. Listening to compiler warnings does not help during code reviews and pre-code-analyses. Especially compilers for embedded systems are rather weak in that point. I know at least one compiler which would not warn in that case even in the highest warning level. Well, you are right, the given example is not the best one. Nevertheless, I like it to see the type of a variable on the fly just by reading code. And the extra typing is the weakest argument against HN. – Babbling

While I agree, eschew Hungerian Notation. I see the C or I prefixing as more a disambiguation mechanism to avoid a class and its interface having the same name (not so evil). H.N., on the other hand, is an ugly/redundent/problematic attempt to make type information (of variables) more conspicuous. Personally I simply Capitalize class names and only prefix with I if it is a COM like interface. – Prieto

@Thomas M.: You are right, you have to test the code where the variable is used. But you have to do this anyway, with or without HN (Hungarian Notation). Since you have to change the naming everywhere, you know what you have to test. This is one of the biggest advantages of the HN and the main reason why we use it. We are developing medical devices. Changing the type of a variable without checking which influences this has is really no good idea, not just for medical devices. HN forces you at least to look where a variable is used if you change the type. – Babbling

@Habi, isn't that "checking everything works" something to be done in [automated] unit/regression tests? – Behold

@Earlz: If the type of a variable is changed, it is necessary to check what influences this has AND whether the existing tests are still suitable/sufficient. Maybe you have to adapt the testing too. – Babbling

The good kind of Hungarian notation can have some vaguely handy uses, such as DIY taint-checking. For instance, you can demarcate a boundary between "safe" (meaning sanitized and/or escaped, usually) strings and "unsafe" strings using Apps Hungarian: uName is an unchecked name fresh from user input, sName is a safe name, uGetName returns an unchecked string, sGetName returns a safe one. char * sEscape(char *uName) launders a string. The handy part is you never pass a variable named u to a function with a parameter named s. Not always worth the effort, of course. – Torment

I don't understand the need for the prefix-all-types kind of HN - in general i already have made a big mistake if i would need it because then i have written my code in a way that it won't trigger compile-time warnings or errors. I acknowledge that i repeatedly make minor errors and try to write in a way so i can catch them at compile-time. – Porky

It's absolutely not evil: it's just an old-fashioned naming convention now largely superseded by powerful IDEs – Tempt

@geo: Apps Hungarian Notation is undoubtedly useful. It allows authors of code to convey semantic information, that cannot (easily) be conveyed otherwise. Like an int that could represent pixels in logical or device units, or the size of a buffer in bytes or characters, and so on. It's challenging, even with today's compilers, to devise custom types for each of those, and providing (sensible) conversions requires exponential effort. In 40 years, C++ has managed to introduce a single unit type (time). That is telling a lot. – Waterbuck

Answer 3

That was a old C++ coding style, and MFC was probably one of the last things to use it.

It was usually just a convention of C++ (and maybe a few other languages), and hence it started falling out of favor as the languages became more interoperable, through COM and then .NET.

You still see it's cousin, the "I" prefix for interfaces, pretty often. I've always found it interesting that "I" survived when "C" died, but that was probably because interfaces were used so heavily in COM interoperability.

Crandale

I think its important to clearly communicate the fact that a class is supposed to be an interface and prefixing with I might still be in wide use as it is shorter and clearer then say a Base suffix. – Porky

It probably didn't die because it addresses minorities (interface, generic type parameters) and the most common (classes) don't get extra clutter. – Stegall

So who else used it? Only Microsoft? – Verine

It is often used in third-party code using MFC/ATL/WTL. By the way, I believe that the last thing that used this convention was actually WTL. A lot of MS code uses it as well - e.g. look at Rotor. – Decile

@Verine - Borland's OWL used T (for type I believe) to prefix class names – Helaina

No, this was never common in C++ land as far as I can tell, Microsoft was the first to prefix with C to distinguish themselves from Apple/Borland which used T. After the first versions of MFC, programmers started to prefix their own classes with C, therefore MS started the thing rather than ended it. I don't remember seeing any C++ book that used C prefixes, not even the 'old' C++ books (mid 80's to 1990's). See jelovic.com/articles/stupid_naming.htm. – Weep

@Roel, My statement was based on the fact that I saw it used in Turbo C++ programs back in the mid-90, well before I ever saw and Microsoft version of C++. Also, that was the naming convention they were teaching in my college in the late 90's, which again wasn't using any MS C++ stuff. But sure, it may have started with MS and filtered down to those other envrionments – Crandale

The I prefix survived mainly for two reasons, a pragmatic one and a technical one. The pragmatic one being, that when you implement a COM object in C++ you usually derive from the interface(s) you implement. You have to name both the object's type as well as the interface, and while they are often the same, the I prefix prevents a name clash. On the technical side, interface types (particularly with COM) show up in method signatures. Once published you cannot change those anymore. We will be seeing the I prefix for as long as COM and/or the Windows Runtime survive. – Waterbuck

Answer 4

I remember Borland compilers were comming with libraries where class names started with 'T'. Probably for "type" :)

Cacia

I always have believed that was because of the T in Turbo Pascal/Turbo C... coding narcissism :) – Mahogany

Answer 5

I can't answer all your questions, but as far as I know, it's just to distinguish the MFC classes from other classes -- a form of Hungarian Notation.

Interestingly, it's apparently controversial not just outside MS, but inside as well.

Regional

yeah well, what do they know - the .NET guidelines (for example) reject the idea of prefixing classes, but are fine with prefixing interfaces. Sometimes the controversy is there for no good reason. – Amsden

Answer 6

Years ago naming convention is crucial to help identifying the class, type of even the grouping of the class. Dont forget back then there was no namespace and no/limited intellisense available. C is a form of Hungarian notation but certainly made popular by MFC. Borland and Delphi was using T - as prefix for Type

Encratis

Another MFC design choice based on what the MS compiler supported twenty years ago rather than how it would be done in modern C++. – Bobsleigh

Answer 7

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.

Resolvable

Answer 8

See here : http://www.jelovic.com/articles/stupid_naming.htm for a long article on this issue.

Weep

Answer 9

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

Strength

Answer 10

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.

Aviation

Answer 11

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.

Mossback

Answer 12

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"

Bottommost