# When the class name is the same as its instance...

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

## Recommended Posts

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?

##### Share on other sites

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.

Edited by EddieV223

##### Share on other sites

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.

##### Share on other sites

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 :)

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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 =)

##### Share on other sites

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.

##### Share on other sites
Programming is not a school subject you have to pass in order to graduate, but if we treat it as one and learn it the way a high school education system would teach it, we could get better standards for programming. It is good to have standards.

People have different conventions for naming variables or plain structuring code. I am a layman so I try to keep it simple.

An apple is a fruit. Therefore an apple belongs to the class of fruit:

class Fruit()

apple = Fruit()

One way to name a class is as a type of something. An apple is a type of fruit. Apple is the instance. Fruit is the class.

Another way to name a class is as a subject

In Math class you learn math.

class Math()

calculus = Math()

But this is incomplete if you don't have a good convention for naming variables and functions so as to distinguish them from class names or one another without checking the camel's back.

Variables are nouns
Functions are verbs.

Functions should be named as actions. If you want to quit a game:

function QuitGame()

If you want to start a game:

function StartGame()

I also have a standard for booleans. I name booleans as participles and as adverbs:

walking = false

if (walking)

quickly = false

if (walking && quickly)

For people who name variables with underscores it is best to put nouns before adjectives as it makes similar variables easier to spot in the code:

apple_red =
apple_green =

boy_mexican =
boy_african_american =
boy_caucasian =
boy_indian =
boy_chinese =

If I want to find a "boy" I can find it easier this way.

Underscores also make things easier to read for me (I used to not understand why people did it).

Anyhow, having standards like these will make code flow better, and keep variable names or class names or function names from getting mixed up.

One more thing, It is good to be specific yet brief in your naming. For example if you have a person class:

class Person()

And you create an instance:

joey = Person()

Then you make joey do "Person" stuff:

joey.Speak()
joey.Walk(quickly)

This is already specific to joey since it uses classes, so your wording shouldn't get mixed up.

However, if it were just a function outside of a class:

Walk()

Then it leaves the questions:

Who or what is walking?
Walk where?
Walking how?

You could do this instead:

WalkFast()
WalkSlow()
WalkLikeYouBrokeYourLeg()

Functions should start with a captical letter and camel-case for each new word
variables start with a lower case letter and camel-case for each new word.

Whether you use underscores or not is up to you. But the two standards above are general for every programming language (at least how schools would teach you).

Writers can write however they want in their journals, but when it comes to writing a research paper, there are standards. Hopefully this helps anyone who reads this post.
Edited by Tutorial Doctor

##### Share on other sites

Tutorial Doctor's examples are the kind of nonsense that made it hard for me to understand objects for several years (many years ago).

My own "standard" goes something like this:

class SpriteSheet {
Texture texture;
// ...
};

// ...
SpriteSheet sprite_sheet;


Upper camel case for classes is extremely common in C++, and I strongly recommend you follow that convention. For local variables and members, start them with lower case, and either use camel case for multi-word names, or use underscores to separate the words. I find underscores easier to read, but either choice is fine.

I noticed that in SFML 1.6 they used upper camel case for everything, which was kind of annoying. In SFML 2.1 they use upper camel case for classes and lower camel case for members, which is a much better choice.

##### Share on other sites

I think Upper case for class names is so common as to say anyone that doesn't use it, by the legal definition of the word, is a deviant. :)

I actually mean that in a way, you make your code downright difficult to grok if you go against such an established tradition ( and yes, SFML < 2 doing that was annoying as hell, and lead to a number of unneeded syntax errors as a result ).

Then again, I when coding for myself use a smattering of the different coding standards I have used throughout my career.

For example, I still use an underscore prefix for private member variables, and ALLCAPS for constants.

##### Share on other sites

C++ standard library is deviant then ;)

Using uppercase letter as first character of your own classes makes it easy to tell which classes are from the C++ standard library though.

##### Share on other sites

C++ standard library is deviant then ;)

Hey, no arguments from me, i've been saying that for years. :D

##### Share on other sites

@Tutorial Doctor

Thanks for trying. I'm incredibly blunt and I think you need to know what went wrong.

I saw how tall your post was, it could have been incredibly insightful, initial impression is everything.

Your use of caps felt confusing as hell.

You lost my interest here.

I am a layman so I try to keep it simple.

An

On the internet I might interpret the caps locking as though you yelled at me.

I wasn't sure if I was seeing constants or classes and couldn't go on. It's like typing "blue orange violet pink." I would never read more unless I signed up to do it.

##### Share on other sites

@Tutorial Doctor

Thanks for trying. I'm incredibly blunt and I think you need to know what went wrong.

I saw how tall your post was, it could have been incredibly insightful, initial impression is everything.

Your use of caps felt confusing as hell.

You lost my interest here.

I am a layman so I try to keep it simple.

An

On the internet I might interpret the caps locking as though you yelled at me.

I wasn't sure if I was seeing constants or classes and couldn't go on. It's like typing "blue orange violet pink." I would never read more unless I signed up to do it.

Ahhh. I didn't consider that all caps are used as constants. doh! Sorry about that. I will edit it. I will see if I can change it to italics.

##### Share on other sites

Hm, I use Java's usual conventions. Use camelCase for everything (cept for Classes) and let the IDE do its magic with fancy colors for further differentiating stuff (say, concrete classes from interfaces).

That way you divide everything into three groups:

• CamelCase    => It's a class/interface.
• camelCase     => Its a variable/field.
• camelCase()  => its a method.

Since you can't have variables written like var(), nor methods omitting the parenthesis (like some languages allow), there is now way you can confuse one with the other.

That's one of my gripes with Delphi (among others). Object.Property.Enable; I don't know if Object is an instance, or a class, if Property is a field, or a getter method, nor if Enable is a field nor a parameterless method that enables something. You have to use prefixes for a bunch of stuff (CObject, GProperty, MEnable) and names just get cluttered.

##### Share on other sites

I can get a bit annoyed when reading code online and seeing letters and classnames being used as variable names (e.g. "int x", "Class class", etc...).

To my mind, your number one priority as a programmer is writing code that is easy to understand - if you need to refactor it later at least you won't have to spend ten minutes trying to figure out how it works.

To answer your question: I would either add a prefix to indicate it being a member variable (Engine m_engine) or put "instance" behind the name of the variable (i.e. Engine engineInstance).

For C++ I actually put a prefix indicating both the fact that it is a member variable and the type it has. A member variable 'sprite' which is a pointer to a Sprite object would be called "m_pSprite", a member variable 'initialized' which is a boolean would be called "m_bInitialized" (some people use the prefix 'is' for booleans so then it would be 'm_isInitialized').

And definitely use the camelCases chubu pointed out - members starting with a capital letter just doesn't seem right to me.

Edited by molehill mountaineer

##### Share on other sites

It irks me a bit to start methods in lowercase because it gets inconsistent with the constructor/destructor in C++. I would have prefered they used more keywords in preference of making everything context-sensitive in C++.

In the example one could still do a constructor call with () or assign the method to a pointer without.

The Pascal/Delphi thing does not originate from people thinking they had to clarify what a function and what a variable is. It came from Borland prepending a T (presumably from Turbo Pascal not type) to the types in the standard library to prevent name-clashes with user code. What they didn't anticipate were uninformed users making it useless for the intended purpose, because, hey standard naming convention I have to copycat.

Edited by wintertime

##### Share on other sites

Upper camel case for classes and other for the instances and member associations.  I really like using a system of prefixes for instances and suffixes for member variables.

... and in any case:  Make sure to use descriptive commenting!

##### Share on other sites

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

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

• ### Forum Statistics

• Total Topics
628666
• Total Posts
2984132

• 12
• 10
• 9
• 9
• 10