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.

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.

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.

C++ standard library is deviant then ;)

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

@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.

@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.

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.

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.

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.