I use PascalCase for classes and camelCase for methods/functions/variables (with "m" prefix for member vars - not "m_"). Because variables and functions wont really be confused (because of the calling syntax), this works pretty well.
I only prefix member vars because intellisense then easily tells me my options when I press 'm', and I dont have to constantly get confused when the logical name of a parameters happens to match that of a member variable.
For globals, something like g_ is almost mandatory IMHO, as they pollute their way into every scope.
For POD structs with no functions, I drop the m_ as you're always going to be accessing them as instance.member anyway.
For larger classes with decent sized functions, something like m_ for members is a great aid in readability and avoidance of common pitfalls -- note that the compiler isn't able to optimize read/writes of members in the same way that it does for local variables, so there is an important performance difference here.
e.g. Both of these are functionally equivalent, but version #2 will compile into much better code:
1) for( int i=0; i!=10; ++i ) { m_count++; printf("%d", m_count); }
2) int count = m_count; for( int i=0; i!=10; ++i ) { count++; printf("%d", count); } m_count = count;
Note that the original "hungarian notation" is actually recommending that you write variable names like m_xPosition vs m_yPosition or m_byteSize vs m_rowSize, which is pretty sane advice.
You write code for humans to read, it's a work of literature. To that end, semantics and readability are paramount.
Pyou vshould pnot vprefix nwords pwith aartificial aencoded pplanguage pconstructs aany amore cthan pyou vshould vdo pso pwith ahuman nspeech. Pit vdoes pnot venhance nreadability.
It is worth mentioning that the history of the C prefix is directly tied to the history of C++. Back when MFC was written C++ namespaces were a horrible mess of half implemented concepts in the compilers and barely worked. C prefix was a useful work around to prevent conflicts in the global namespace. There were other examples of this such as an entire Os where all classes were prefixed with B I believe it was. Anyway, as others have mentioned, C++ has moved on and prefixes are rarely desirable compared to using namespaces. Also, as others have said, certain types of instances still tend to use Hungarian notations such as g_ or variations.
My preferences are generally:
namespaces instead of class prefixes.
often I will use a 't' in front of template class names to differentiate a utility template from a base class, but it is generally only in the case where the template is a helper to implement boilerplate code over the base class.
generally I use the g_ or other prefix to differentiate special scoping of items.
Unless I'm using a class style enum, I tend to drop a little 'e' in front of enumeration types. I.e. enum Blargo {eFail} versus enum class Blargo {Fail}.
The point of listing this is to reinforce what others have said: while the class names themselves have moved along, there are still reasons to for similar practices in other areas of the language. So long as you come up with a consistent set of rules, you can write clean code.
I tend to use verb/noun/adjective to describe methods, classes, and interface. Collidable, for example, is an interface. There are a few cases where it may not be immediately clear at first glance, in which case a simple "Go To Definition" would suffice.
The only prefix I use is underscore for reserved class/global variables that I certainly don't want conflicts to happen. Because you have to be pretty deliberate to use an underscore as the first char. Even that does not happen a lot.
PascalCase for classes, camelCase for automatic/member variables and functions, g_globalvariable, s_staticvariable, IInterface, and some sort of prefix if there's semantics to the variable outside of the actual type.
I don't prefix classes but I prefix constants with k (I seen that in C4 and liked it), private fields of classes with m_ and name my enums in all caps with underscores and prefix them with E and then name enum members (except count that is name + _COUNT) E + (initials of words in enum) + their own name (that's an idea from Irrlicht, except I think they name count value the same as the rest of the values).
enum ESTUFF_CONFIGURATION_TYPE
{
ESCT_FAST = 0,
ESCT_ACCURATE,
ESCT_GENERIC,
ESTUFF_CONFIGURATION_TYPE_COUNT
};
This is so constants stand out in code and so that I never need to look an enum value up if I don't remember names of its values. I just type E and the initials and use autocomplete. It also helps when reading code that they stand out from other names and have initials of the type in them so it can hint me into remembering what this value meant. I probably should use C++11 enums instead but full name + name of value gets a little long and sometimes I want implicit int and I don't want to have two types of enums (old and the 11 ones) in use...
It's kinda redundant to prefix classes with C but it doesn't affect readability or use at all in my opinion. Smart function and class naming and design and being smart about dependencies (both included and linked ones) is way more important to me for accessibility and readability than that single letter being there.
Note that the original "hungarian notation" is actually recommending that you write variable names like m_xPosition vs m_yPosition
Am I going blind, what's the difference there?
I've simplified to the essentials over the years. I prefix for interfaces, cause C# still rolls that way and I like it. (Non-pure abstract base classes are suffixed with Base, usually.) Single underscore to label _private or _protected class variables*. And g_ for globals because those should look gross. That's pretty much the extent of it.
* The underscore thing also works great in languages that don't HAVE private scoping, or when I don't actually private scope them but they're considered implementation details.
