🔒 Locked

Prefix Class Names with 'C' Good Practice?

Started by Raeldor Sep 3, 2005 at 10:59 AM 14 replies 12.9k views

Original Post

Sep 3, 2005 at 10:59 AM

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

SiCrane

Sep 3, 2005 at 11:03 AM

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.

rKallmeyer

Sep 3, 2005 at 11:11 AM

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;

Raeldor

Sep 3, 2005 at 11:17 AM

Will using...

// 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

nmi

Sep 3, 2005 at 11:42 AM

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.

JohnBolton

Sep 3, 2005 at 1:29 PM

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.

Raeldor

Sep 3, 2005 at 1:36 PM

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?

Oxyd

Sep 3, 2005 at 2:34 PM

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

SirLuthor

Sep 3, 2005 at 2:44 PM

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.

kSquared

Sep 3, 2005 at 5:46 PM

I prefer the .NET naming guidelines. They make sense and they're not wonky with crazy conventions.

Glak

Sep 3, 2005 at 9:31 PM

Ok first question: should I start off class names with C? I'm going to give you a short answer here but by far the best answer that anyone will give you is found at this link:

http://www.joelonsoftware.com/articles/Wrong.html

I assume that you know something about type safety. You can't assign a Texture to a Mesh, because the compiler won't let you. You can name a function f and you can name a class c, but the compiler won't let you do this will it: f=c; No of course not, because such statements are nonsense and the compiler recognizes them as such, thanks to compile-time type checking.

Now sometimes you don't have as much typesafety as you need. Let's say that you are using a simpler language, maybe C or even something simpler, or maybe other factors prevent you from using all of the features that C++ offers. Your program deals a lot with array indices and color values. You decide to represent both in your code using unsigned integers.

However is a Color an array index? If you have a variable named color_of_shirt and another named index_into_shirt_properties would it make any sense to do something like this: index_into_shirt_properties = color_of_shirt; Well no, because an index and a color aren't the same thing. So not only is that code wrong, but it is nonsense. However both are unsigned ints, so the compiler can't catch this kind of nonsense.

Thus in this case a naming convention will catch your error by making the code look wrong. Would putting ui (for unsigned int) onto the from of either variable have helped. The answer is a resounding NO. If your language provides a feature let the compiler take care of it, it if doesn't then and only then should you step in.

Oh and for your second question:

Instead of doing this:
Matrix Matrix;
do this:
Matrix matrix;
or if the variable is of a very limited scope (never leaves the screen) do this:
Matrix m;

Oluseyi

Sep 3, 2005 at 11:10 PM

Quote:
Original post by Raeldor
Will using using 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?

It won't "override" it; it'll simply generate a name collision at compile-time. This is when you fully qualify your types. Contrived example:

#include <vector>struct vector{ // blah;};vector v;                           // my own vector typestd::vector< vector > myvectors; // no confusion

But what if they're from two external libraries?

#include <Lib1_Matrix.h>#include <Lib2_Matrix.h>// this function uses Lib1::Matrix mostly, only using Lib2::Matrix in a few placesvoid func1(){  using Lib1::Matrix;  Matrix a;  ...  Matrix b;  ...  Matrix c;  ...  Lib2::Matrix d;  ...}

Congratulations, you finally understand the flexibility and intent of the C++ using directive. And, yes, it would be nice if you could alias things like L1Matrix = using Lib1::Matrix or some less-ugly equivalent. *shrug*

Conner McCloud

Sep 3, 2005 at 11:38 PM

Quote:
Original post by Oluseyi
And, yes, it would be nice if you could alias things like L1Matrix = using Lib1::Matrix or some less-ugly equivalent. *shrug*

typedefs would get you pretty far in this regard, although they might not offer the scoping behavior that you may want.

CM

Promit

Sep 3, 2005 at 11:42 PM

Quote:
A typedef declaration introduces a name that, within its scope, becomes a synonym for the type given by the type-declaration portion of the declaration. You can use typedef declarations to construct shorter or more meaningful names for types already defined by the language or for types that you have declared.

Which suggests that typedef does what Oluseyi asks.

C0D1F1ED

Sep 4, 2005 at 2:19 AM

I recently found this: C++ Programming style Guidelines. It's a collection of all most common styles. It's very close to the style I personally use, and it gives good motivations for every rule.

The only thing I don't fully agree with is to add an underscore to a private member (rule 11). I just use "this->" to unambiguously denote members. This is also how it's done in Java and it reads very fluently.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.