Prefix Class Names with 'C' Good Practice?
Author
Is it good practice to prefix all class names with 'C', ie 'CTexture'? I see this done in some places but not others. The reason I ask is that the compiler seems to get confused when I have a class called 'Material' and also a member called 'Material' and try to do something like 'Material=new Material()'. Also, I am re-writing some existing classes (Matrix) that need to co-exist with their GDI counterparts.
The other option I guess is namespaces, but I am a little confused as to how this works. With GDI+ already defining the Matrix class, then having my own, if my class is in a different namespace, and I use the 'using MyNamespace' at the beginning of the module, it still gets confused. Do I need to explicitly use the namespace when I use the classname, ie something like 'MyNameSpace::Matrix newMatrix'? Is there a way to just tell the compiler to use your namespace to resolve any conflicts?
Thanks
The obvious solution is to use a naming convention so that your variable names and your class names don't overlap. For example, I make variable names look like_this and class names look LikeThis.
In general, using C to prefix a class is denote the class as a concrete type as compared to the use of I to denote the class as a interface.
In general, using C to prefix a class is denote the class as a concrete type as compared to the use of I to denote the class as a interface.
Quote:Original post by Raeldor
Is it good practice to prefix all class names with 'C', ie 'CTexture'? I see this done in some places but not others. The reason I ask is that the compiler seems to get confused when I have a class called 'Material' and also a member called 'Material' and try to do something like 'Material=new Material()'.
It's a matter of personal preference or the coding standard of the institution or company you work for. I have seen use use of capitalization for classes much more common the the use of a prefix-C.
For example:
ClassName (Title Caps)
variableName (like class names but first variable lower case)
StaticData, StaticFunction (Title Caps)
privateData_, privateMethod_ (like variable name with underscore)
In the end it is just a tool to enhance readability, so when you adopt a new coding standard, make sure you ask yourself - does it make it easier to read?
Quote:
The other option I guess is namespaces, but I am a little confused as to how this works. With GDI+ already defining the Matrix class, then having my own, if my class is in a different namespace, and I use the 'using MyNamespace' at the beginning of the module, it still gets confused. Do I need to explicitly use the namespace when I use the classname, ie something like 'MyNameSpace::Matrix newMatrix'? Is there a way to just tell the compiler to use your namespace to resolve any conflicts?
Thanks
Yes, and you can do it in two ways:
// Only do this in a cpp file// to use the entire namespace included within the headerusing namespace MyNameSpace;// to use just a bit from the namespaceusing MyNamespace::Matrix;
Author
Will using...
Override a declared standard C structure such as Matrix in GDI+, or will it still be unresolvable when you reference it in a function?
Thanks
// to use just a bit from the namespaceusing MyNamespace::Matrix;Override a declared standard C structure such as Matrix in GDI+, or will it still be unresolvable when you reference it in a function?
Thanks
Quote:Original post by Raeldor
Is it good practice to prefix all class names with 'C', ie 'CTexture'? I see this done in some places but not others. The reason I ask is that the compiler seems to get confused when I have a class called 'Material' and also a member called 'Material' and try to do something like 'Material=new Material()'. Also, I am re-writing some existing classes (Matrix) that need to co-exist with their GDI counterparts.
It is a good practice to have a naming convention and use it consequently.
There are many of such conventions out there, but you are free to create your own.
The style I am using is this:
#define ALL_UPPERCASE_WITH_UNDERSCOREtemplate <typename OtherType>class ClassWithMixedCase { typedef int count_t; void doSomething(); // mixed-case starting lower case, a verb int memberVariable; // mixed-case starting lower case, a noun};In the case of 'Material', you should use a different style for types than for members.
Quote:
The other option I guess is namespaces, but I am a little confused as to how this works. With GDI+ already defining the Matrix class, then having my own, if my class is in a different namespace, and I use the 'using MyNamespace' at the beginning of the module, it still gets confused. Do I need to explicitly use the namespace when I use the classname, ie something like 'MyNameSpace::Matrix newMatrix'? Is there a way to just tell the compiler to use your namespace to resolve any conflicts?
A namespace is perfectly fine for this case. But never ever put a using directive in a header file. (or better said, in global scope)
This may cause compile errors that are hard to track. If you need to use a name often in a function, you may put the using directive at function scope like this:
void doSomething()
{
using namespace std;
cout << "hello world" << endl;
}
Another thing when using namespaces is to make the namespace's name part of the inclusion guard. So for a class math::Matrix instead of
#ifndef MATRIX_H
better write
#ifnder MATH_MATRIX_H
or something similar. (maybe _MATH__MATRIX_H_)
So if there are two matrix classes that happen to have the same scheme for naming the inclusion guards, they will still have distinct names.
Putting a 'C' on the front of every class name is about as useful as putting a 'V' on the front of every variable name and an 'F' on the front of every function name.
Author
Quote:Original post by JohnBolton
Putting a 'C' on the front of every class name is about as useful as putting a 'V' on the front of every variable name and an 'F' on the front of every function name.
Now it's starting to sound like hungarian notation. :P
So I am guessing that now in the days of intellisense and better IDE's that this is no longer any advantage?
With prefixing classes with C- you're emphasising the language, instead of the problem. When you write Car rolls_royce; it's obvious you're creating a Car -- why do you want to know that internally Car is a class? If you don't know what member function class Car has then the fact of knowing it's a class doesn't help you any.
Oxyd
Oxyd
Putting 'C', or most anything for that matter, in front of class names is, in my opinion, a godawful sin, worthy of death, or at least extreme pain. Far better to have a good naming convention and to use namespaces, then to prefix things with an ugly letter to denote what it is. If anything, you should prefix objects of that class, rather then the class itself. Isn't everything you create in essence a class? Just like with hungarian notation, in a strongly typed language, it just isn't necessary. Now, there are cases where I feel prefixes (or postfixes) are a good thing, such as in function or template arguments, to denote what it is, and make things easier for the reader (and for me!) when it is referenced in the code, but those are the only places where I feel justified using them.
Quote: Putting a 'C' on the front of every class name is about as useful as putting a 'V' on the front of every variable name and an 'F' on the front of every function name.
fFunc() a function that returns a floating type. :)
I agree with SirLuthor to some extent, using namespaces and good naming conventions is probably the best way to go. I would raise issue with abandoning warts (the funky hungarian prefixes) altogether since intellisense does occasionally malfunction. In the end, it's all a matter of preference, if you feel that it is of paramount importance that you know that a certain class is in fact a class, then go ahead and use the 'C' prefix.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
