I run into this problem a lot. Sometimes a class's name is very simple. Like Renderer, Terrain, Brush, etc... Now you want to have an instance of that. What makes it harder for me is that i use upper camel case for members!

Suggestions?

Upper camel case for variables seems unusual.

I think there is always a way to express the purpose of the instance. Even if it is just defaultRenderer, currentRenderer or the like.

Renderer renderer; variable

Renderer mRenderer; class member field

Renderer pRenderer = new Renderer(); pointer variable

Renderer mpRenderer = new Renderer(); pointer class member field

This style works well and is recommended by the author of Code Complete.

Upper camel case for variables seems unusual.

Really? I use lower case for function/local variables but upper case for member variables. Maybe i should switch to lower case or use a prefix like m.

I just haven't seen them named that way. However I also have my own special non-conforming code guidelines, so do what you like :)

Hello,

It is imperative that you stay with the habit of software architecture planning to establish class names - at least most of them - before you begin coding. Flow charts are so very important to advancing in game development. Each stage could use a flow chart. After testing of the module, you should make note at the end of the flow chart that implementation was tested and verified. Any notes for future issues should go near the bottom, too.

Version control (source control) software helps with the design, construct, debugging and implementation. Flow charts can be tied to version control.

I know a lead programmer for an international firm. He often talks about flow charts as being key to things such as class names and instances. In coding, the better the programmer then the more sophisticated the documentation tends to be. It consumes time short term, but yields massive savings in time and effort long term as an investment.

My suggestion is if it bothers you to not be able to use the same name then just change your coding convention. Otherwise its really best if you find something at least a little more descriptive for the current use in a variable than the type name.

Personally I use like using upper camel case in C++ for things not changing at runtime like types, classes and methods; and lower camel case for variables. I dont see value in hungarian notation, thats why I dont use m prefixes.

My suggestion is if it bothers you to not be able to use the same name then just change your coding convention. Otherwise its really best if you find something at least a little more descriptive for the current use in a variable than the type name.

Personally I use like using upper camel case in C++ for things not changing at runtime like types, classes and methods; and lower camel case for variables. I dont see value in hungarian notation, thats why I dont use m prefixes.

The m and p prefixes are not hungarian notation. Hungarian notation involves prefixing with the type, such as i for int f for float and even coming up with your own prefixes for other classes.

The m p just denote the scope and either pointer or variable.

My suggestion is if it bothers you to not be able to use the same name then just change your coding convention. Otherwise its really best if you find something at least a little more descriptive for the current use in a variable than the type name.
Personally I use like using upper camel case in C++ for things not changing at runtime like types, classes and methods; and lower camel case for variables. I dont see value in hungarian notation, thats why I dont use m prefixes.

The m and p prefixes are not hungarian notation. Hungarian notation involves prefixing with the type, such as i for int f for float and even coming up with your own prefixes for other classes.

The m p just denote the scope and either pointer or variable.

Actually, I believe the original form of Hungarian Notation was closer to your example (see this), and became widely misused in the way you describe. /nitpick =)

My suggestion is if it bothers you to not be able to use the same name then just change your coding convention. Otherwise its really best if you find something at least a little more descriptive for the current use in a variable than the type name.
Personally I use like using upper camel case in C++ for things not changing at runtime like types, classes and methods; and lower camel case for variables. I dont see value in hungarian notation, thats why I dont use m prefixes.

The m and p prefixes are not hungarian notation. Hungarian notation involves prefixing with the type, such as i for int f for float and even coming up with your own prefixes for other classes.

The m p just denote the scope and either pointer or variable.

Actually, I believe the original form of Hungarian Notation was closer to your example (see this), and became widely misused in the way you describe. /nitpick =)

In either case it's nothing like my notation.