CClassname
Author
I know this is a religious debate for some people, but why CClassname? I''ve read many rants on the net that agree with the fact that MS chose it to use in MFC so it''d stand out, but when everyone uses it, it loses value. It seems rather redundant to me and I read so many posts that have it, so I just had to know what the rationale is behind it.
It becomes somewhat more useful when you want to clearly distinguish between classes and interfaces.
Don''t listen to me. I''ve had too much coffee.
Don''t listen to me. I''ve had too much coffee.
I use it just to distinguish between e.g. classes and enums (class CUnit & enum EUnit [although i tend to say enum EUnitType]). I know people will say that i should name my classes better, but i still do it this way.
I also use hungarian notation to determine what type a variable is without having to find its declaration and to shorten identifier names (e.g. pszBuffer instead of ptrStringBuffer), so i guess prefixing the ''C'' is part of hungarian notation.
[HTTP 500 x3]
2p
I also use hungarian notation to determine what type a variable is without having to find its declaration and to shorten identifier names (e.g. pszBuffer instead of ptrStringBuffer), so i guess prefixing the ''C'' is part of hungarian notation.
[HTTP 500 x3]
2p
Author
quote:Original post by Sneftel
It becomes somewhat more useful when you want to clearly distinguish between classes and interfaces.
Can''t you just prefix an I to it like "iSocket" or "ISocket" (if you hate Apple
). That is a useful naming convention I think. Seems like the C is extraneous.
People prefix class names with C so that they can remember that CBitmap is not a basic type.
Perhaps we ought to prefix all function names with fn? Oh, wait, I can tell which identifiers are function names because of the context in which they are used:
Gosh, it looks like I''ll have to find another way to make work.
void fnAFunctionName () {}class CAClassName {}; int main (){ CAClassName someObject; fnAFunctionName ();} Gosh, it looks like I''ll have to find another way to make work.
null_pointer: Ah, but what about:
But i think thats just silly
void (*foo)(); foo bar = Wibble; But i think thats just silly
quote:Original post by antareus
Can''t you just prefix an I to it like "iSocket" or "ISocket" (if you hate Apple
i is int! ;p
enum enEnumeration { one=1, two, three };
class CBanana;
int iFrogCount;
struct Apple sFruit;
typedef void tFruit;
unsigned short usFiddlers;
unsigned long ulCucumbers;
void * vpFrog;
long * lpMoose;
class Foo
{
public:
unsigned short* m_uspUshortPointer;
};
and so on.
ITS RELIGION!
What does God want?
Does God want goodness or the choice of goodness?
Is a man who chooses the bad perhaps in some way better than a man who has the good imposed upon him?
quote:null_pointer: Ah, but what about:
That is exactly my point. You can isolate any little bit of code and make an argument that Hungarian Notation will help because it attaches extra type information to most identifiers; however, the argument is flawed. Even if you attach "fn" prefix to function pointer typedefs, you still have no knowledge of what that function actually does. You should not be working on code you do not understand in the first place. It is generally more effective to improve your coding skills by learning to choose more clear and concise identifiers than it is to mutilate the code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
