# Naming a class

This topic is 3788 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi there, I've created a class that encapsulates functionalities that concern text output (in OGL) but, out of lack of creativity, the only name I could come up with was GText, which, as you can see, has nothing to do with "text output." Crappy me... So I thought that maybe I could ask the creative minds on gamedev.net to come up with suggestions to a name for my class? The only rule is it must start with "G". Fire away!

##### Share on other sites

TextRenderer
TextRenderingFactory

##### Share on other sites
My vote goes with TextRenderer. I see no reason why the class should be prefixed with G, the letter doesnt imply OpenGL and if you want to indicate the class belongs to a library then use a proper namespace.

##### Share on other sites
Yes, drop the G. We aren't barbarians here.

##### Share on other sites
//! OpenGL-related utility classesnamespace GLUtil {  //! Display-related utilities  namespace Display {      //! A bit of text shown on the screen    class Text;    //! A cache for data shared between text objects    class TextCache;  } }

##### Share on other sites
Definitely I'm going to go for CTextRenderer and I'm going to follow your recommendations and drop the G. You're absolutely right, the way forward is to encapsulate the classes within namespaces. The only reason I went for the prefix 'G' instead of 'C' was to give the classes a stand outish meaning, one in the lines of 'GSomething', a graphics related class. I suppose I'm better off sticking to the standards... thanks for pointing that out to me.

Now, allow me to expose yet another question, which concerns how to best make my set of text renderer and font classes work in a multi-threaded environment. First off, here's the hierarchy I've come up with:

class CFreeType		// wrapper class for the FreeType library, is accessed by CManagerFontsclass CManagerFonts	// creates and removes fonts, holds the currently active font, 			// and encapsulates font dataclass CTextRenderer	// does text rendering only and (constly) accesses CManagerFontsFont data is contained in CManagerFonts in:	struct FONT_NODE	{		BYTE	_height;	// height of the font		BYTE*	_pWidths;	// array containing widths for each char of the font		GLuint	*_pTex;		// array texture's ids		GLuint	_listId;	// first display list id	};

An instance of CManagerFonts and CTextRenderer always exists at all times, while CManagerFonts manages when to instantiate/destroy CFreeType to suit its needs.

Also, a handle is returned every time a font is created, which is then passed into a method in CManagerFonts to make it the current one. This handle is nothing but a POSITION type (CAtlList), which is a pointer to a FONT_NODE.

Then, whenever the app needs to output text it invokes one of a set of methods in CTextRenderer, which then makes use of the currently active font.

Seeing there can be only one font active at any given time, you can see problems will potentially occur in a multi-threaded environment where different threads use different fonts to output text concurrently.

Two ways I've thought to counter this was to either pass in a font handle to methods in CTextRenderer (though it isn't very convenient) or to change FONT_NODE and make it a class of the likes of CTextRenderer (the more logical way IMHO.)

What is your opinion on this? In light of your personal experience, do you think I could do this a better way, come up with a better design?

Many thanks to all of the posters for their precious replies!

##### Share on other sites
Quote:
 Original post by hellraiserDefinitely I'm going to go for CTextRenderer and I'm going to follow your recommendations and drop the G. You're absolutely right, the way forward is to encapsulate the classes within namespaces. The only reason I went for the prefix 'G' instead of 'C' was to give the classes a stand outish meaning, one in the lines of 'GSomething', a graphics related class. I suppose I'm better off sticking to the standards... thanks for pointing that out to me.

The C is not any better. Just TextRenderer, please.

What do you think the C communicates? Why do you think the person using the class *cares about* this? Or didn't s/he already know?

##### Share on other sites
The "C" is just an annoying extra character to type. There's no point... what is it meant to indicate? A class and a struct are basically the same thing--especially from the perspective of a developer using it--and you certainly will never confuse a TextRenderer with a primitive type like int, char, float, double, etc.

##### Share on other sites
When I started out I thought I would use all that prefix Hungarian notation stuff too. But most people, myself included, just end up using a very small subset of that notation.

For example all I use is:

m_varName - to indicate a member variable
szStringName - to indicate a c-style null terminated string
typename_t - For typedef'd types (*RARELY*)
g_varName - For global variables (*RARELY*)

The rest is just too verbose for my taste. Besides if you have a good IDE, just highlighting over the variable name will reveal its type.

In conclusion: Use visual studio and drop all those annoying prefix C's and G's :)

[Edited by - fpsgamer on August 5, 2007 11:31:06 AM]

##### Share on other sites
Quote:
 Original post by fpsgamerFor example all I use is:m_varName - to indicate a member variableszStringName - to indicate a c-style null terminated string

You usually don't even need those. If you have a variable named "name", or "nickname", or "password", or whatever, then it's typically pretty self-evident what the type is. And, to be honest, I've simply NEVER had a situation arise where I was tearing my hair out trying to figure out what the precise type of the "fooName" variable was.

And if I have any large blocks of code where it isn't immediately obvious which variables are locally declared, I fully name the member variables with "this->"... I used to use the m_ prefix, but found that it was simply not helpful to me.

Your mileage may vary, of course.

##### Share on other sites
Quote:
Original post by smitty1276
Quote:
 Original post by fpsgamerFor example all I use is:m_varName - to indicate a member variableszStringName - to indicate a c-style null terminated string

You usually don't even need those. If you have a variable named "name", or "nickname", or "password", or whatever, then it's typically pretty self-evident what the type is.

Not really.

The the variable "password" could be c-string or an std::string. Hell it could be an array of four integers.

##### Share on other sites
Quote:
Original post by fpsgamer
Quote:
Original post by smitty1276
Quote:
 Original post by fpsgamerFor example all I use is:m_varName - to indicate a member variableszStringName - to indicate a c-style null terminated string

You usually don't even need those. If you have a variable named "name", or "nickname", or "password", or whatever, then it's typically pretty self-evident what the type is.

Not really.

The the variable "password" could be c-string or an std::string. Hell it could be an array of four integers.

Which is immaterial since your module will use the same type for anywhere a password is used.

Even if you *did* need to know the type, it can be retrieved from an even vaguely modern IDE without entangling the type with the variable name and all the downsides that come along with that.

##### Share on other sites
Quote:
 The the variable "password" could be c-string or an std::string. Hell it could be an array of four integers.

Not if you make a rule for yourself to use std::string for strings...

The problem with Hungarian is that if you decide to switch from c-string to std::string (or some other type) you can easily forget / not bother to update the identifier accordingly, leading to a variable name which is wrong about the type.

Another reason I don't prefer prefixes is that it would cause autocomplete to offer too many false suggestions requiring me to type more (or waste time selecting the right suggestion).

##### Share on other sites
Personally, I only prefix by scope. Meaning that class members are prefixed by a small 'm' (no underscore) and globals (on the rare occasion that they exist) are prefixed by a small 'g' -- Intellisense already tells you what the variables are, but it doesn't tell you anything about scope.

I would use 'this->' explicitly, but I often find that it collides with my desired parameter names. Even though 'this->' solves the ambiguity, it still takes a little extra thought. I'd rather avoid the potential for bugs where I write a new value out to a parameter (having neglected the 'this->' prefix) and then wonder why my member variable was reflecting the stored value.

Other than that, I tend to follow the C# naming guidelines, as I find them to be pretty modern and consistent.

The only class prefix I use is a large 'I' for interfaces.

##### Share on other sites
My convention is:
CONSTANTS_ARE_ALL_CAPS_WITH_UNDERSCORES,
TypesIncludingClassesStructsAndTypedefsAreUpperCaseCamelNotation
functionsAreLowercaseCamelNotation
andSoAreVariables
_unlessTheyArePrivateThenTheyGetAnUnderScorePrefix
and I dont use globals

Quote:
 Seeing there can be only one font active at any given time, you can see problems will potentially occur in a multi-threaded environment where different threads use different fonts to output text concurrently.Two ways I've thought to counter this was to either pass in a font handle to methods in CTextRenderer (though it isn't very convenient) or to change FONT_NODE and make it a class of the likes of CTextRenderer (the more logical way IMHO.)

This is perhaps down be my minimalistic experience with multi-threaded programming, but I dont see how this helps?
Also theres no real difference between a class and a struct, its only syntatic.

Is there a reason why each thread cant have its own font manager and renderer?

Also the name CManagerFonts seems a bit backwards to me, firstly drop the C, then something like FontManager sounds better. Although is this manager really a factory? or a facade maybe? Perhaps something like FontFacade is more suitable? If not, then maybe you can split the font manager into two classes and then make a facade that houses these two classes and the font renderer and thus ensuring they all exist at the same time. Just a thought [smile]

##### Share on other sites
Thanks everybody for their suggestions and comments. Regarding my identifier naming practices I think I've been using MsVS series (especially MFC) for far too long.

I agree with everyone's comments: a prefixed class name doesn't really tell much more than what the programmer who is about to use it already knows. I therefore must absolutely agree that employing a good combination of namespace class/global vars/etc encapsulation coupled with prefix-free class naming practices makes more sense. In fact, it makes all the sense.

I still think though that it is useful to use a small subset of the Hungarian notation (as someone pointed out above) when it comes to naming class attributes and globar vars. Maybe you disagree?

Quote:
 Is there a reason why each thread cant have its own font manager and renderer?Also the name CManagerFonts seems a bit backwards to me, firstly drop the C, then something like FontManager sounds better. Although is this manager really a factory? or a facade maybe? Perhaps something like FontFacade is more suitable? If not, then maybe you can split the font manager into two classes and then make a facade that houses these two classes and the font renderer and thus ensuring they all exist at the same time. Just a thought.

Totally agree that CManagerFonts sounds too backwards! FontManager it will be, thanks for pointing that out to me. As for its role, FontManager is a factory/container holding all the fonts created by the app. Other classes such as TextRenderer interact with it, through accessors only, to retrieve information about the font they're using. Trouble is, it only supports one active font at any given time, which means that if two threads are rendering text concurrently using different fonts, erractic behaviour will most likely occur.

Mind you, I've not tested this, as I've not had the need to deevlop a multi-threaded app yet. I'm only thinking about the ifs-whens and their likely consequences.

Again, thanks to everybody for their extremely useful posts.

PS: Does anyone know of a good up-to-date link where I can read up on good identifier naming practices in C++? I really feel I need to re-educate myself.

##### Share on other sites
Quote:
 Original post by hellraiserI still think though that it is useful to use a small subset of the Hungarian notation (as someone pointed out above) when it comes to naming class attributes and globar vars. Maybe you disagree?

I disagree.

I use this->membername in all situations where it is not obvious that I am accessing a member variable—this avoids redundant m_name or _name information in initializer lists (only members), member access obj.name (only members), member pointers Class::name (only members) and one-line read-only functions return name (no possible confusion). This leaves very few situations where the variable is ambiguous, and I then use this->name (it's also useful for brining up IntelliSense).

I use Scope::global (or ::global) for global variables.

Quote:
 PS: Does anyone know of a good up-to-date link where I can read up on good identifier naming practices in C++? I really feel I need to re-educate myself.

This is for java, but it applies to C++ as well.

##### Share on other sites

This topic is 3788 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.