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?
how many naming conventions do you use at work, really? ;-P
Marcus Lindblom
2010-02-18 22:01:51
One per developer? ;)
Georg Fritzsche
2010-02-18 22:05:43
by many I meant C for classes, p for pointer, m_ for members, s_ for static members, n for integer ... not many documents :)
f4
2010-02-18 22:13:42
+2
A:
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.
mwigdahl
2010-02-18 21:56:20
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.
gbjbaanb
2010-02-18 21:58:45
+6
A:
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.
Mike Mooney
2010-02-18 21:56:54
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.
Georg Fritzsche
2010-02-18 22:00:42
It probably didn't die because it addresses minorities (interface, generic type parameters) and the most common (classes) don't get extra clutter.
F.Aquino
2010-02-18 22:05:42
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.
Pavel Minaev
2010-02-19 01:32:23
@User1 - Borland's OWL used T (for type I believe) to prefix class names
dkackman
2010-02-19 02:58:34
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 http://www.jelovic.com/articles/stupid_naming.htm.
Roel
2010-02-19 12:29:26
@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
Mike Mooney
2010-02-19 15:00:22
+7
A:
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.
Earlz
2010-02-18 22:00:16
@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.
Habi
2010-02-18 22:30:02
@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?
UncleBens
2010-02-18 22:40:47
@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. :-(
Thomas Matthews
2010-02-18 23:24:01
@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.
Habi
2010-02-18 23:25:03
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.
Roger Nelson
2010-02-18 23:25:35
@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.
Habi
2010-02-18 23:42:46
@Habi, isn't that "checking everything works" something to be done in [automated] unit/regression tests?
Earlz
2010-02-18 23:47:06
@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.
Habi
2010-02-19 00:01:38
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.
Steve Jessop
2010-02-19 00:57:57
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.
Georg Fritzsche
2010-02-19 01:16:53
+6
A:
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.
Steve Jessop
2010-02-19 00:47:55
+3
A:
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
Fadrian Sudaman
2010-02-19 00:58:51
Another MFC design choice based on what the MS compiler supported twenty years ago rather than how it would be done in modern C++.
Pete Kirkham
2010-02-19 11:07:00
+2
A:
I remember Borland compilers were comming with libraries where class names started with 'T'. Probably for "type" :)
Nemanja Trifunovic
2010-02-19 02:52:00
+1
A:
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.
Dr. Watson
2010-02-19 03:12:14
+1
A:
See here : http://www.jelovic.com/articles/stupid_naming.htm for a long article on this issue.
Roel
2010-02-19 12:24:27
A:
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.
rmxz
2010-09-17 17:04:32