There's no convention oter than the one you establish yourself. Of course some things should never be done, like using long names or naming a variable apples when it should be named oranges. The key point is consistency. Use the same style throughout the application. And choose your own. As you keep programming, no matter the language, you will soon find yourself adopting one.
. My classes start with C followed by word capitalized names. CPlayer, CHouse, CInventory.
. My private data members all end with an underscore and no capitalization. name_, status_, level_.
. Private member functions follow the same naming convention for data members. As in fact, anything that is private does.
. I prefer to separate words with underscores. blast_radius.
. operator overloading usually has pretty simple semantics. If another user defined object, it's called simply obj. If a std::string or C-style string, it's called str. All arithmetic types are called val. On non member operator overloading I always prefix with l and r (standing for left and right operand)
I usually have a few personal rules I try to stick to. Some probably good, some probably bad, some probably outright wrong:
. I postfix all pointers (and the same with pointers defined inside a class) with _ptr. player_ptr, account_ptr.
. If I'm using safe pointers, I postfix owner pointers with _ptr as normal (even if I'm using shared pointers), but weak pointers with _wptr.
. All my iterators are named iter. If the name already exists in scope due to another iterator presence, I append x, y, z, m or n respectively (this is from my school days in naming variables for math calculations).
. Following the same convention as above reverse iterators are named riter, and insert operators are named iiter.
. My regular variables are usually all small_caps with words separated by underscores.
. function parameters, are a special case. I almost always try to make them follow the same rules as for operator overloading above. If the meaning of the variable is non-important, it will invariably be called str, obj, val, or some other generic name. I will otherwise use a regular variable name, if I think the meaning of the variable is important to understand the code inside the function or it's important in order to understand the context of the function.
I can't remember any more examples... There are more. The important bit is for you to be consistent about it. This is not a part of the programming language. It's a part of you. It's part of your coding style. Everyone reading your code is not asked to like or not your coding style. They are required instead to understand it. And you are required to make it easy for them by being consistent.
