[ACCEPTED]-Class names that start with C-hungarian-notation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0

we use it at work, like many other naming 3 conventions

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

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

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

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

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